Bug#1010248: ITP: wlgreet --
Package: wnpp Severity: wishlist Owner: Marc Dequènes (Duck) X-Debbugs-Cc: debian-devel@lists.debian.org Control: block -1 with 1010247 * Package name: wlgreet Version : 0.3 Upstream Author : Kenny Levinsen * URL : https://git.sr.ht/~kennylevinsen/wlgreet * License : GPL-3 Programming Lang: Rust Description : raw wayland greeter for greetd Greeter to be run under sway or similar. Note that cage is currently not supported due to it lacking wlr-layer-shell-unstable support. This ITP is intended to be fulfilled once greetd is packaged, see #1010247. I was thinking about maintaining it into the Rust team but I have not joined yet. Regards. \_o< -- Marc Dequènes
Bug#1010247: ITP: greetd -- minimal and flexible login manager daemon
Package: wnpp Severity: wishlist Owner: Marc Dequènes (Duck) X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: greetd Version : 0.8.0 Upstream Author : Kenny Levinsen * URL : https://git.sr.ht/~kennylevinsen/greetd * License : GPL-3 Programming Lang: Rust Description : minimal and flexible login manager daemon greetd makes no assumptions about what you want to launch. Use gtkgreet to launch sway if you want a fully graphical session, or use agreety to launch a shell if you want a drop-in replacement for agetty(8) and login(1). If you can run it from your shell in a TTY, greetd can start it. If it can be taught to speak a simple JSON-based IPC protocol, then it can be a greeter. Most login managers historically assumes X11. The most compatible one is probably GDM but unless you use GNOME you may wish to have a more lightweight solution. Lightdm worked well until recently despite not having Walyland support itself but it is now afflicted by this bug: https://github.com/swaywm/sway/issues/6655 The last release dates 2018 and there is no recent coding activity. I think greetd's architecture properly decouples authentication and the login UI and makes for a good replacement for Wayland users. I was thinking about maintaining it into the Rust team but I have not joined yet. Regards. \_o< -- Marc Dequènes
Re: shim-signed
On 2022-04-26 at 18:05, Paul Wise wrote: > On Tue, 2022-04-26 at 20:41 +0200, Bastian Blank wrote: > >> secure boot signing process at Microsoft is a review-sign process > > What kind of review are Microsoft doing of the Debian shim? > > Are they reviewing the source and checking for a reproducible build? I'd be curious to have a more in-depth answer to this, myself. My understanding has always been that they check to make sure that what they're signing is not visibly malicious, and in most cases also that it can't chain to load something else (which isn't signed, and might be malicious). Since the entire purpose of the shim - at least as I understand it - is to chain to load something else, clearly either that understanding is not correct, or they're making an exception for the case of the shim. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: shim-signed
On 2022-04-26 at 10:14, Marc Haber wrote: > On Sat, 23 Apr 2022 18:21:47 +0100, Steve McIntyre > wrote: >> Alternatively, people can build replacement shim-signed packages >> using their own root of trust if desired. If we had a large enough >> number of users wanting a different root of trust, we could even >> offer our own different shim-signed package to match. > > I would probably prefer to have grub an/or the kernel signed, > avoiding additional code, but maybe having some explanation would > convince me that the shim actually improves things additionally to > adding complexity. My understanding has always been that the point of having a Microsoft-signed shim, rather than having Microsoft sign GRUB or the kernel, is to A: avoid the need for round-trip with Microsoft's signing facilities every time the GRUB or kernel packages are updated, and B: ensure that end-users can still build their own kernels (et cetera) without having to go through the Microsoft signing process, even if their systems are set up to take advantage of the signed shim. (And the point of having Microsoft sign it, rather than using a signing key under the control of e.g. Debian, is that Microsoft's key is already considered valid by the relevant firmware environments - including the ones that can't be told to add another key to the list of valid ones. That avoids having another barrier to entry, in the form of a set of steps at the start of the install process which is going to be different per UEFI designer, and is also going to be complex and unintuitive from the perspective of a non-technical potential new user.) I can't speak to how big of an advantage A is, but B seems to me to be pretty important. If that understanding is not correct, I'd be interested to learn what the actual point of having the shim is. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: shim-signed (was: Firmware - what are we going to do about it?)
On Tue, 2022-04-26 at 20:41 +0200, Bastian Blank wrote: > secure boot signing process at Microsoft is a review-sign process What kind of review are Microsoft doing of the Debian shim? Are they reviewing the source and checking for a reproducible build? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: shim-signed (was: Firmware - what are we going to do about it?)
Moin On Tue, Apr 26, 2022 at 04:14:02PM +0200, Marc Haber wrote: > On Sat, 23 Apr 2022 18:21:47 +0100, Steve McIntyre > wrote: > >We don't have good docs around this in general (hey, it's security > >software - it's against the law to write good and complete docs!), but > >I've certainly discussed this with a few folks over the years. > It would be great to have that written down somewhere to tell poeple > what they're actually doing. Something like https://wiki.debian.org/SecureBoot? > >Alternatively, people can build replacement shim-signed packages using > >their own root of trust if desired. If we had a large enough number of > >users wanting a different root of trust, we could even offer our own > >different shim-signed package to match. > I would probably prefer to have grub an/or the kernel signed, avoiding > additional code, but maybe having some explanation would convince me > that the shim actually improves things additionally to adding > complexity. All the UEFI parts (GRUB, kernel) and also the kernel modules _are_ signed. Otherwise this whole stunt would be kind of useless. However, secure boot signing process at Microsoft is a review-sign process, aka you send the binary to the authority and get a signature back. They don't provide a signed certificate, which you could use to sign stuff at will, as you would do with an e-mail (to be exact, S/MIME and secure boot uses the same signature format). So it is simply not possible with the existing process, to sign everything with it. So shim was introduced, which is signed using the review process, and adapts the signing to accept signatures done by another CA, which is controlled by Debian and used to sign everything. Regards, Bastian -- Extreme feminine beauty is always disturbing. -- Spock, "The Cloud Minders", stardate 5818.4
Re: shim-signed (was: Firmware - what are we going to do about it?)
Marc Haber wrote: >On Sat, 23 Apr 2022 18:21:47 +0100, Steve McIntyre > >>Better than that, our shim-signed source package always double-checks >>things here. At build time it removes the Microsoft signature and >>compares that shim binary to the binary that we submitted for >>signing. We would spot immediately if there was any code added. > >And if that check fails at build time, the Debian process refrains >from putting a Debian signature on the deb and from uploading? Can the >end user build the shim herself, remove the signature from the signed >shim and compare the binary, preferably in a documented way? Look at the shim-signed source - the build will fail if the code has changed. -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Re: shim-signed (was: Firmware - what are we going to do about it?)
On Tue, 2022-04-26 at 16:04 +0200, Marc Haber wrote: > On Sat, 23 Apr 2022 13:54:59 +0200, Ansgar wrote: > > Why? > > If only I knew. I myself don't feel to comfortable to rely on > Microsoft being able to pull the plug on us any time. I don't know > whether they can, but I imagine some kind of revocation mechanism > being in place. As with all certificate systems, the revocation system is fairly broken ;-) > > Because it contains a third-party signature for which the private > > key is not included in Debian? The same is true for signatures in > > debian-archive-keyring, debian-keyring, ca-certificates, wireless- > > regdb, and many other packages. > > A running system doesn't rely on any of those. It will also work if Secure Boot is disabled (which should be possible on at least all x86 systems). If you want Secure Boot w/ Microsoft's key[1], then you obviously have to rely on Microsoft's key. [1]: As far as I understand, one reason it's Microsoft's key is that nobody else wanted to run a CA for this. > > Debian's buildds build shim (binary package: shim-unsigned); the > > binary generated by Debian is then signed by Microsoft's key. > > And we have a mechanism to check whether the code is actually the > same? You can do that even manually: +--- | $ diff -u <(hexdump -C ../s/usr/lib/shim/shimx64.efi) <(hexdump -C shimx64.efi.signed) | head -n 26 | --- /proc/self/fd/11 2022-04-26 16:35:32.983515245 +0200 | +++ /proc/self/fd/17 2022-04-26 16:35:32.983515245 +0200 | @@ -11,12 +11,12 @@ | 00a0 00 72 06 00 00 00 00 00 00 20 02 00 00 20 02 00 |.r... ... ..| | 00b0 00 00 00 00 00 00 00 00 00 10 00 00 00 02 00 00 || | 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || | -00d0 00 00 0d 00 00 04 00 00 9b 82 0e 00 0a 00 00 00 || | +00d0 00 00 0d 00 00 04 00 00 bb af 0e 00 0a 00 00 00 || | 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || | * | 0100 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 || | 0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || | -* | +0120 00 00 00 00 00 00 00 00 e8 1f 0e 00 78 21 00 00 |x!..| | 0130 00 f0 07 00 0a 00 00 00 00 00 00 00 00 00 00 00 || | 0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || | * | @@ -57279,5 +57279,540 @@ | 000e1fb0 44 00 6c 6f 61 64 5f 6f 70 74 69 6f 6e 73 00 50 |D.load_options.P| | 000e1fc0 4b 45 59 5f 55 53 41 47 45 5f 50 45 52 49 4f 44 |KEY_USAGE_PERIOD| | 000e1fd0 5f 69 74 00 58 35 30 39 5f 4e 41 4d 45 5f 45 4e |_it.X509_NAME_EN| | -000e1fe0 54 52 59 5f 69 74 00 |TRY_it.| | -000e1fe7 | +000e1fe0 54 52 59 5f 69 74 00 00 78 21 00 00 00 02 02 00 |TRY_it..x!..| | +000e1ff0 30 82 21 6b 06 09 2a 86 48 86 f7 0d 01 07 02 a0 |0.!k..*.H...| | +000e2000 82 21 5c 30 82 21 58 02 01 01 31 0f 30 0d 06 09 |.!\0.!X...1.0...| +--- If I remember correctly: - the first change (~0xd0) should be a checksum of either the file or just the header - the second change (~0x120) is the offset of the signature table in the database (0xe1fe8) and its size. - the third change (~0xe1fe0) is appending the signature You can also extract the signature, attach the signature to the unsigned file and verify you get the same binary (src:shim-signed does this[2]). [2]: https://salsa.debian.org/efi-team/shim-signed/-/blob/52f43dc447fdc4fbb948a5883c0a04077aeb7dd4/Makefile#L9 One could also teach diff tools to strip/ignore signatures. This would be useful if we decide to sign ELF executables, files lists or binary package themselves: without excluding the signature, no package would be reproducible any longer... Ansgar
Bug#1010210: ITP: orthanc-neuro -- Neuroimaging plugin for Orthanc
Package: wnpp Severity: wishlist Owner: Sebastien Jodogne X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: orthanc-neuro Version : 1.0 Upstream Author : Sebastien Jodogne * URL : https://book.orthanc-server.com/plugins/neuro.html * License : GPL Programming Lang: C++ Description : Neuroimaging plugin for Orthanc This package adds support for neuroimaging in Orthanc, notably to easily convert from DICOM to NIfTI.
Re: shim-signed (was: Firmware - what are we going to do about it?)
On Sat, 23 Apr 2022 18:21:47 +0100, Steve McIntyre wrote: >We don't have good docs around this in general (hey, it's security >software - it's against the law to write good and complete docs!), but >I've certainly discussed this with a few folks over the years. It would be great to have that written down somewhere to tell poeple what they're actually doing. >Alternatively, people can build replacement shim-signed packages using >their own root of trust if desired. If we had a large enough number of >users wanting a different root of trust, we could even offer our own >different shim-signed package to match. I would probably prefer to have grub an/or the kernel signed, avoiding additional code, but maybe having some explanation would convince me that the shim actually improves things additionally to adding complexity. >Better than that, our shim-signed source package always double-checks >things here. At build time it removes the Microsoft signature and >compares that shim binary to the binary that we submitted for >signing. We would spot immediately if there was any code added. And if that check fails at build time, the Debian process refrains from putting a Debian signature on the deb and from uploading? Can the end user build the shim herself, remove the signature from the signed shim and compare the binary, preferably in a documented way? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: shim-signed (was: Firmware - what are we going to do about it?)
On Sat, 23 Apr 2022 13:54:59 +0200, Ansgar wrote: >On Sat, 2022-04-23 at 12:21 +0200, Marc Haber wrote: >> >Is the presence of shim-signed on the install media enough to make >> >people feel somehow contaminated? >> >> I think so, yes. Personally, I don't care too much but i can >> understand why some people might. > >Why? If only I knew. I myself don't feel to comfortable to rely on Microsoft being able to pull the plug on us any time. I don't know whether they can, but I imagine some kind of revocation mechanism being in place. And it's anther lay of indirection. While RFC compliant (1925, 6a) this introduces another possible attach vector since shim-signed might have to do its own check about the kernel to load. I do not know zilch about the shim, but this might be an issue for people. > Because it contains a third-party signature for which the private >key is not included in Debian? The same is true for signatures in >debian-archive-keyring, debian-keyring, ca-certificates, wireless- >regdb, and many other packages. A running system doesn't rely on any of those. >If we were to include more signatures in binary packages (e.g., a >signed manifest listing files (with hashes) shipped by the package, >signed executables, an embedded signature for the .deb itself), would >that be a problem? > >We do include signatures for source packages (*.dsc and also for >upstream tarballs) as well. I would LOVE to have an easier possibility to check the actual uploader's signature for anything in the archive short of squatting on every changes file ever visible. >> We can compile shim-signed and compare the signed code with our own >> object code, can't we? That we we would only have to worry about the >> validity and benignness of the signature and not worry about having >> undocumented functionality in the signed code. > >Debian's buildds build shim (binary package: shim-unsigned); the binary >generated by Debian is then signed by Microsoft's key. And we have a mechanism to check whether the code is actually the same? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Firmware - what are we going to do about it?
Dear developers, if like to here an opinion from the useer side, please listen. I made many installations of debian in the last years, mostly notebooks preinstalled with windows. What often lacks is, that on many newer notebooks the network card is not accessible. Either due of missing firmware or because the network card is not included in the old installer kernel (speaking of debian/stable). This includes wireless and wired cards. Especially Intel, Atheros and Realtec cards are involved in this issue. So, if you ask me, what should be improved: 1. For installation the latest kernel should be used. Can be deinstalled after installation. 2. All (and I mean ALL!) firmware should be available on the installer. This means not, they should be installed. It should be installable, but must not forcely be installed. Maybe it CAN be installed, when it is needed during the installation. 3. Kernel developers (and that is only a suggestion!), should take care , that "debian/stable" kernels support newest hardware. Just my 2 cents Best regards Hans
Re: Firmware - what are we going to do about it?
On 4/26/22 12:08, Andrey Rahmatullin wrote: On Tue, Apr 26, 2022 at 11:59:20AM +0300, Hakan Bayındır wrote: No, they do not. Most popular devices won't work at all without non- free firmware, including boring things such as mass storage (SD cards, SSD, HDD, ..., and controllers), input devices (keyboards, mice, ...). Yeah, you’re right. Since the firmware images always there and doesn’t need to be hot-loaded by the driver itself 99% of the time (for these classes of devices), I tend to forget about them. Note that this fact was mentioned many times in this thread. I personally didn't have the time to follow/reread all of the thread unfortunately, however considering here's a development thread with a lot of knowledgeable people, it's of course expected. I wonder whether these “proper” firmware can be considered as part of the hardware, FSF and/or some FSF proponents certainly think like this. Others just conveniently ignore it completely. I didn't come to that point by being a FSF "proponent", but starting at an early age with a Commodore 64, and learning that firmware is something inside that you can't proverbially touch or update, then being able to touch it as my knowledge accumulates and firmware becomes closer to surface as the technology evolves. I always believed that everything should be open and accessible before I knew about Linux or FSF. These are just two things which align with my values well, and I use Debian for 15 years, since it's the best aligning distribution with my values, amongst many other things. I have no intention to derail the discussion by moving the goalposts or to "conveniently ignore" things. since it’s bundled with the hardware, but not with the driver itself. In the Linux world loadable firmware is rarely "bundled with the driver". This includes the use case discussed in this thread. By bundled with the driver I didn't mean "Linux World", but the bundle you receive from the vendor, mostly for Windows environment, and the media where the firmware lives (in the hardware vs. the driver image). Probably the days when Linux is considered as a second class citizen by most hardware vendors is still too ingrained in me. I wasn't clear enough, sorry about that. This makes matters more complicated, of course, but starting somewhere may create the same wedging effect as in the drivers, over time. Such arguments seem to ignore that 1) it's not about "starting somewhere" because we aren't discussing something we will need to decide before some point in the future: the situation exists for many years, we are discussing whether we should change how to handle it, not how to start handling it; 2) the often mentioned expected effect on hardware manufacturers should be already felt in some form as the status quo of not providing any non-free firmware on the official image is many years old; 3) so far the usability of systems with the official image becomes worse, not better, over time. I'm aware of all three, and this is why I proposed a 6th option as my first message to this thread, which consists of creating a tool which combines the firmware.zip and the current free image to a USB flash drive and directly "burn" it, as an "automagic" solution, allowing users to assemble their images without complicating things on the policy side much. Again, to reiterate, I'm not "hard-against" adding firmware images to the official ISO and asking a question about installing them during installation, but considering the role and place of Debian among the Linux distributions, I just want to highlight that the choices done here will probably have a ripple effect, so we need to consider it correctly and have to be well-aware of the ethical implications, the DFSG and the Social Contract. And not undermine these two inadvertently with the actions we take. Hope it's more clear now, Regards, H.
Re: Firmware - what are we going to do about it?
On Tue, Apr 26, 2022 at 11:59:20AM +0300, Hakan Bayındır wrote: > > No, they do not. Most popular devices won't work at all without non- > > free firmware, including boring things such as mass storage (SD cards, > > SSD, HDD, ..., and controllers), input devices (keyboards, mice, ...). > > Yeah, you’re right. Since the firmware images always there and doesn’t > need to be hot-loaded by the driver itself 99% of the time (for these > classes of devices), I tend to forget about them. Note that this fact was mentioned many times in this thread. > I wonder whether these “proper” firmware can be considered as part of the > hardware, FSF and/or some FSF proponents certainly think like this. Others just conveniently ignore it completely. > since it’s bundled with the hardware, but not with the driver itself. In the Linux world loadable firmware is rarely "bundled with the driver". This includes the use case discussed in this thread. > This makes matters more complicated, of course, but starting somewhere > may create the same wedging effect as in the drivers, over time. Such arguments seem to ignore that 1) it's not about "starting somewhere" because we aren't discussing something we will need to decide before some point in the future: the situation exists for many years, we are discussing whether we should change how to handle it, not how to start handling it; 2) the often mentioned expected effect on hardware manufacturers should be already felt in some form as the status quo of not providing any non-free firmware on the official image is many years old; 3) so far the usability of systems with the official image becomes worse, not better, over time. -- WBR, wRAR signature.asc Description: PGP signature
Re: Firmware - what are we going to do about it?
> On 26 Apr 2022, at 11:30, Ansgar wrote: > > On Tue, 2022-04-26 at 10:47 +0300, Hakan Bayındır wrote: >> While I understand where you're coming from, I don't think such thing >> is necessary, because a) Most popular devices with non-free firmware >> blobs already work without such firmware > > No, they do not. Most popular devices won't work at all without non- > free firmware, including boring things such as mass storage (SD cards, > SSD, HDD, ..., and controllers), input devices (keyboards, mice, ...). Yeah, you’re right. Since the firmware images always there and doesn’t need to be hot-loaded by the driver itself 99% of the time (for these classes of devices), I tend to forget about them. I wonder whether these “proper” firmware can be considered as part of the hardware, since it’s bundled with the hardware, but not with the driver itself. This makes matters more complicated, of course, but starting somewhere may create the same wedging effect as in the drivers, over time. > >> , albeit with a lower performance >> (e.g. Realtek NICs), and b) The drivers gracefully handle the lack of >> firmware already, with a couple of harmless "ERROR:" messages. > > I would assume such NICs actually come with preinstalled non-free > firmware which just has less functionality... I generally envision them as an old school hardware with some ARM cores attached, and the functionality is disabled since you don’t fire up the ARM core with the proper so-called “program”. > > I get the impression you pretend that preinstalled non-free firmware > just doesn't exist. Ah no, it’s a honest brain-short. Since I exposed to a lot of hardware over the decades, my brain tends to categorize resident, non-updatable firmware as part of the hardware itself, since you have no access to it as you don’t have access to the silicon. Sorry for the unintentional misunderstanding and possible tension. Cheers, H. > Ansgar >
Re: Firmware - what are we going to do about it?
On Tue, 2022-04-26 at 10:47 +0300, Hakan Bayındır wrote: > While I understand where you're coming from, I don't think such thing > is necessary, because a) Most popular devices with non-free firmware > blobs already work without such firmware No, they do not. Most popular devices won't work at all without non- free firmware, including boring things such as mass storage (SD cards, SSD, HDD, ..., and controllers), input devices (keyboards, mice, ...). > , albeit with a lower performance > (e.g. Realtek NICs), and b) The drivers gracefully handle the lack of > firmware already, with a couple of harmless "ERROR:" messages. I would assume such NICs actually come with preinstalled non-free firmware which just has less functionality... I get the impression you pretend that preinstalled non-free firmware just doesn't exist. Ansgar
Re: Firmware - what are we going to do about it?
On 4/26/22 09:12, Ansgar wrote: On Mon, 2022-04-25 at 23:48 +0300, Hakan Bayındır wrote: While what you’re saying is technically true, the default selection means much more than a default. It’s defines the stance of Debian, as a whole. [...] So, if Option 5 is adopted, the default state is as important as the step itself IMHO. I also still believe that giving people the tools for assembling their "firmware enabled” install media is a valid option, but it’s not favored as far as I can see (no hard feelings, though). And we stay a possibility for FSF-people. FSF people condemned Debian long ago: https://www.gnu.org/distros/common-distros.html#Debian While I like and support what FSF is standing for, I don’t think their “condemnation” is a valid reason for not pursuing the ideals DFSG puts forward. In my opinion, DFSG is one of the things underpins the essence of Debian, and is a force for creating a more free and open world. We’re almost there on the driver side, and while it gonna take some time, we can be there on the firmware side. We just have to be persistent, sometimes stubborn even. Maybe then the "DFSG-free" installer should also exclude drivers for devices that require non-free firmware, including preinstalled non-free firmware? It could also show a message indicating that such devices are not supported (if possible). People could still assemble their "non-free firmware enabled" install media including such drivers. While I understand where you're coming from, I don't think such thing is necessary, because a) Most popular devices with non-free firmware blobs already work without such firmware, albeit with a lower performance (e.g. Realtek NICs), and b) The drivers gracefully handle the lack of firmware already, with a couple of harmless "ERROR:" messages. It's worth noting that the drivers in question are already free software and might have functionality over time to support newer devices of the family which might have open firmware, or ideally the firmware code is published retroactively. Moreover, I guess excluding such drivers would require a new CI/CD pipeline, and may require new kernel packages complicating the situation further, for both users and maintainers alike. My ideal to make things as frictionless and transparent possible, while making the transition between two states as easy. I don't believe we have to decide between DFSG and convenience. A more gradual spectrum should be possible. Cheers, H. Ansgar
