Package request - gEDA and pcb
by Henrik Karlsson
I don't know if this is the right place to request packages to be added so
please just ignore me if I wrong. Or you could direct me to the right
place.
I would like to have the the following programs added to Fedora:
gEDA - GPL Electronic Design Automation
Used for drawing schematics for electronics. It's quite good and has
active development. The program can be found at http://geda.seul.org
pcb - a program for drawing print circuit boards
This program is used in combination with gEDA-tools to make a pcb-layout
of the circuit. It's a GPL licensed program. The program can be found at
http://sourceforge.net/projects/pcb/ .
//henrik
19 years, 10 months
libGL and libGLU buildtime dependancy virtualization
by Mike A. Harris
There are various libGL and libGLU implementations floating
around nowadays and generally speaking, most applications that
link to either library do not require any specific
implementation.
In Red Hat packaging, libGL and libGLU have both moved from
package to package and subpackage to subpackage over time.
Applications which link to these libraries do not and should not
hard code a dependancy on the binary rpm package that provides
either of these runtime libraries, as rpm's autoreqprov script
will set the dependancy on the actual library rather than the
package it is included in. This has the benefit that as long as
any implementation of the library is installed on the system via
rpm, at the same filesystem location as what an application was
linked to, rpm package installation will be happy, even if you
have a different libGL installed than was used to link the
application.
In plain english, building fooGL on a stock Red Hat OS
installation with all packages installed, will cause fooGL to be
linked to the Mesa libGL which is included with the X
implementation included in the OS (either XFree86 or X.Org,
depending on OS release). RPM will automatically add a runtime
dependancy on:
libGL.so.1
or more accurately on "libGL.so.<version>" that the app was
linked against. As long as you have the Red Hat package that
includes libGL.so.1 installed, the dependancy is met at runtime,
even if we move libGL to a different package at some point.
(It's moved from Mesa to XFree86-libs to xorg-x11-libs over the
years). Regardless of what package provides this library, all
apps relying on rpm dependancy checking should be happy.
Problem:
Buildtime dependancies. In order for your libGL and libGLU
packages to have proper BuildRequires lines that specify all
required build/devel dependancies, you need to specify what
packages provide the needed headers and .so symlinks. This
causes a problem because the package that includes the libGL and
libGLU headers has changed over the years, and it is possible it
will continue to change in the future from time to time.
If you want to make an rpm package that has all of it's
BuildRequires specified correctly, and links to libGL, and is
buildable on all Red Hat Linux 7.x releases, Red Hat Enterprise
Linux, and Fedora Core 2, you'll have a slight problem, because
the libGL and libGLU headers are in 3 different binary rpms
across that range of OS releases. Currently, there are 2 ways
people can resolve this in an OS neutral fashion:
1) Specify a build dependancy on the actual header file:
ie: BuildRequires: /usr/include/GL/gl.h
or
2) Use rpm macros to select one of 3 different build
dependancies, based upon which OS target the package is being
built for:
%if %{build_mesaGL}
BuildRequires: Mesa-devel >= 3.4.2
%endif
%if %{build_XFree86_mesaGL}
BuildRequires: XFree86-devel >= 4.2.0
%endif
%if %{build_xorg_x11_mesaGL}
BuildRequires: xorg-x11-devel >= 6.7.0
%endif
>From the two above, #1 is obviously simpler and probably the most
used. #1 will also work with any rpm packaged libGL, and not
just the ones that Red Hat has shipped.
One problem with either approach however, is that it does not
specify a particular libGL API version, and there is no easy way
to do so.
Another problem, is that some rpm packagers will put a
BuildRequires: XFree86-devel to pick up the libGL headers, but
that will make their rpm package not rebuildable on X.Org, or
vice versa.
What I am considering doing, to try to solve these problems, is
to start including virtual provides for libGL-devel from now on
to all rpm subpackages which provide the libGL development
headers and symlinks.
Example for X.Org X11 would be adding the following to our
xorg-x11-devel subpackage dependancy information:
%define libGL_version 1.2
...
Provides: libGL-devel = %{libGL_version}
The same would be done for libGLU, and possibly other libraries.
RPM packagers could then start using the virtual BuildRequires to
pick up the correct libGL headers, etc.:
BuildRequires: libGL-devel >= 1.2
It would likely take a couple of OS releases before these changes
would catch on, but it's a longterm future-proofing that will
IMHO help keep build dependancies libGL agnostic and X11
implementation agnostic (and agnostic as to wether X11 is
installed at all).
Before I add these changes to our X.Org packaging for FC3
however, I wanted to hear some constructive feedback and
other ideas from others. If I go ahead with the changes, I will
eventually add similar changes to future updates of XFree86 and
X.Org X11 for previous OS releases that we still support, so that
people can start using the virtual provides sooner than later.
Your feedback is appreciated.
TIA
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - X11 Developer - Red Hat
19 years, 10 months
FC3 request
by Brian Millett
I would like to see an update to the orinoco drivers. At least to what
the latest RC1 provides. The newer rev allow scanning, or monitor mode.
Thanks.
--
Brian Millett
Enterprise Consulting Group "Shifts in paradigms
(314) 205-9030 often cause nose bleeds."
bpmATec-groupDOTcom Greg Glenn
19 years, 10 months
Re: Musings about on-disk encryption in Fedora Core
by W. Michael Petullo
> - encrypted swap
This shouldn't be too hard. There are a lot of scripts out there that do
this. The only issue is the timing of things. Generally, encrypted swap
needs to be initialized after the RNG entropy pool. As mentioned before,
this is probably a prerequisite to all of the other encryption features.
> - encrypted file system partitions or logical volumes
I am working on implementing encrypted root filesystem support to mkinitrd.
See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124789 for more
information and an patch.
> - user owned encrypted storage (encrypted loop devices, can substitute
> encrypted directories to a certain degree)
This can be implemented pretty nicely using pam_mount
(http://www.flyn.org/projects/pam_mount/index.html) because pam_mount can
unlock filesystems at login time using a user's system authentication token.
An article I wrote for the Linux Journal on the subject of encrypted home
directories is available at http://www.flyn.org/docs/ehd.pdf. Note that
there have been some changes to pam_mount since the article's publication
last year.
There is also an active bug that asks for encrypted filesystem support in
general: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=56698.
--
Mike
19 years, 10 months
Re: Musings about on-disk encryption in Fedora Core
by W. Michael Petullo
>>> Securing the system is exactly the same thing IMHO.
>>>
>>> If your system is insecure then encryption won't help, the attacker will
>>> get all your passwords and happily decrypt all your data!
>> I would argue that it depends on what you are securing against. For
>> example, securing data against physical laptop theft does not really
>> require booting from removable media...as long as you don't trust the
>> laptop once it is recovered.
>
> True. But what about servers? How secure is YOUR server room? Taking
> disks out etc is not difficult to do. Replacing the BIOS on the
motherboard
> adds an extra level of difficulty and the risk is decreased if that is what
> an attacker would be forced to do.
You are entirely right. Again, my point is that it depends what you are
securing against. I don't have a server room. I am interested in securing
my laptop. The important thing is that, as these techniques are developed,
we are straight forward with and aware of the precise things they defend
against.
>> However, if you are requiring a physical token to provide a key then
>> booting from that token is not too much of a leap. Assuming your firmware
>> supports booting from, say, USB. This seems outside the scope of mkinitrd
>> and more a responsibility of properly configuring yaboot, lilo, grub, etc.
>
> You need the initrd to be able to mount an encrypted root fs, so there are
> some changes to initrd needed. They are probably more significant than the
> changes to allow booting from a USB device.
Yes. I am already working on modifying mkinitrd (see elsewhere in this
thread). So, as I mentioned, once mkinitrd/initrd supports encrypted root
filesystems and accessing a key on a removable device then booting from that
same device should be simple.
--
Mike
19 years, 10 months
Musings about on-disk encryption in Fedora Core
by Nils Philippsen
Hi,
I realize that it's a tad too late in the FC3 cycle, but I couldn't help
thinking about on-disk encryption and how to integrate it into Fedora
Core over the last week or so.
The state of affairs as far as I can see is that we finally have
everything low-level, both kernel- and userspace, i.e. we have
device-mapper and dm-crypt along with assorted cipher algorithms on the
kernel side and dmsetup and cryptsetup tools on the user side. I'll talk
about block-device level encryption and will leave out features a'la
Windows-like encrypted directories which need support from the file
system.
While this all can be used rather easily for your needs if you are
willing to fiddle a bit, there is virtually no real integration into the
operating system, none I have found anyway ;-).
Talking about on-disk encryption, one should differentiate some "use
cases". I would split it up like this, sorted by estimated effort to
implement:
- encrypted swap
- encrypted file system partitions or logical volumes
- user owned encrypted storage (encrypted loop devices, can substitute
encrypted directories to a certain degree)
Encrypted swap space is pretty much a prerequisite for everything else
because you don't want data that's encrypted on another device lying
around decrypted in swap space. Fortunately this as well as encrypted
file system volumes (except the root device and /boot) are fairly easy
to implement, e.g.:
both swap and fs:
- have an fstab like list containing:
- real device
- device mapper device to be accessed from VM or FS layer
- crypto parameters (like algorithm, key length, ...)
- reference the device mapper device from /etc/fstab
swap:
- generate a random passphrase from /dev/random or /dev/urandom
- attach to en/decrypting device mapper device
- mkswap
- swapon
fs:
- ask for the passphrase very early in the boot process
- attach to en/decrypting device mapper device
- sanity check whether the passphrase is correct (look for FS magic
numbers or the like), if wrong, re-ask for a couple of times
- continue boot process (fsck, mount, ...)
Leaving aside the question how desirable it is to have the root fs
encrypted on disk, this is more complicated than the above -- you'd need
to put this all in the initial ramdisk, i.e. enhance mkinitrd, add some
tools to the initial ramdisk (causing bloat ;-), there is no way to
specify crypto parameters in a configuration file (which is still
encrypted at that time. Having /boot encrypted would be even more
complicated (and less desirable), because you would have to teach boot
loaders about how to deal with encrypted partitions. In my opinion let's
rather teach them about LVM instead ;-).
User owned encrypted storage on Linux -- which can be mounted when
needed and unmounted later -- is very different to handle. At the moment
it boils down to loopback images owned by the users with some means for
the user to:
- losetup the image
- attach it to en/decrypting device mapper device after asking for the
pass phrase (sanity checking like above)
- probably r/o sanity fsck on the device
- mount device mapper device somewhere accessible by the user
All of this would need to be wrapped up in a package, probably with a
nice UI around it, at least as long mount doesn't support asking for
pass phrases etc. and it could be done with more traditional Unix means
;-). We would then need to find a balance between flexibility (rather
not ;-) and security (as most of this needs root privileges), probably
starting with no "user-configurable data" and work up from there if
necessary, i.e. hardcoded paths for a single image file and mount
directory and small easily auditable tools to setup the environment and
to mount/umount which in turn can be used by a GUI or else.
This all needs changes/development in:
swap + normal fs: initscripts and installer
root fs: ditto plus mkinitrd
user owned crypto storage: toolset as described
To keep all this sane and portable some items (like configuration files
etc.) should maybe be discussed more widely than only on this list so
this stuff could work on other distros as well.
What do you all think?
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
19 years, 10 months
Re: Musings about on-disk encryption in Fedora Core
by W. Michael Petullo
>> If my system password is not unknown to others then my encryption
>> password is probably no good either. I think root has to be trusted in
>> most cases. I would be interested to hear any arguments that "only
>> mount[ing] the encrypted, potentially sensitive stuff when you need it"
>> would be more secure than unmounting encrypted volumes a login time
>> (assuming a strong system authentication token).
> If I have a different password, there is no representation of it on disk
> (like crypt() or MD5 hashes of a login password). There's a reason my
> PGP pass phrase is different from my login password as well ;-). If one
> is compromised, the other isn't.
As I mentioned, I am assuming a strong system authentication token. As you
mention, storing MD5 hashes on disk is not a strong system authentication
token. But I'm sure one could produce a technique for storing passwords on
disk that would be as difficult to decipher as performing a known plain text
attack on your on-disk encrypted data.
I would also argue that if I have access to your account than I eventually
have access to your PGP keys. I can install something in .bash_profile and I
can read your process memory, right?
I suppose that one could argue that all these passphrases and passwords are a
defense in depth technique, but here is a fundamental problem: your system
authentication token says to the system "this is me" and if that is not the
case then all else is eventually doomed.
--
Mike
19 years, 10 months
Re: Musings about on-disk encryption in Fedora Core
by W. Michael Petullo
>>> For a really secure system you have to boot from removable or read-only
>>> media.
>>> If an attacker can compromise the kernel image that you boot from then
>>> they can own you. If you have an unencrypted kernel/initrd stored on the
>>> hard disk then you must either keep the hard disk locked up at all times
>>> (in which case encrypting it doesn't gain much) or treat every unexpected
>>> reboot as a potential compromise.
>> I was concentrating mainly on means to secure data (against prying eyes,
>> not corruption), securing a system is a completely different kind of
>> thing.
> Securing the system is exactly the same thing IMHO.
>
> If your system is insecure then encryption won't help, the attacker will
get
> all your passwords and happily decrypt all your data!
I would argue that it depends on what you are securing against. For example,
securing data against physical laptop theft does not really require booting
from removable media...as long as you don't trust the laptop once it is
recovered.
However, if you are requiring a physical token to provide a key then booting
from that token is not too much of a leap. Assuming your firmware supports
booting from, say, USB. This seems outside the scope of mkinitrd and more a
responsibility of properly configuring yaboot, lilo, grub, etc.
In addition, when you boot from removable media, you really need to
authenticate that you are booting from the removable media. Perhaps the boot
process could tell you a secret that only you and the removable media know.
If the attacker has access to the firmware then the attacker may cause the
computer to spoof your normal boot process. A firmware password may or may
not help, depending on how paranoid you are.
So we can go down any number of paranoid trails (and we should). But that
doesn't mean we shouldn't start "picking at the low hanging fruit" to make
progress. We just need to be straight forward about what we are protecting
against (for example, a stolen laptop vs. a stolen laptop that I can trust if
returned).
--
Mike
19 years, 10 months