Re: Firmware - what are we going to do about it?
On Thu, 21 Apr 2022 10:12:19 -0700, Russ Allbery wrote: >I've been a Debian Developer for quite some time and can usually manage to >figure out most tasks like this, and providing separate firmware to the >installer has completely defeated me every time I've tried it. I've spent >frustrated hours trying to follow the documentation and doing things that >look right only to have the installer say that there's no firmware visible >without any clue as to how to debug the errors. Every time I have tried >this, I have eventually given up and found the non-free images, which just >worked. Amen. I know one installation with a five digit number of Debian systems that uses a hacked installer with the Kernel from CentOS because that one just works. I have talked to the guy who did that operation (one of the most competent IT people I know) and he said nearly the same as Russ said. >If this is going to be the solution, it has to be WAY easier to do. Yes, absolutely. 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
shim-signed (was: Firmware - what are we going to do about it?)
On Fri, 22 Apr 2022 11:16:42 +0200, Philip Hands wrote: >I understand the urge to insist upon absolute DFSG purity in the media >we produce, but when it comes to wanting to avoid every last shred of >data that we could not regenerate ourselves, I think we crossed that >line some time ago. > >I'm thinking of shim-signed, which is included in our official media. > >Despite being free software in source form, it is signed by Microsoft, >and can only be expected to work with that signature ... which we cannot >create. > >On most (all?) hardware one is able to avoid UEFI secure-boot, so won't >need to use shim-signed, but I'd imagine that some hardware insists on >secure-boot, or the opt-outs are somehow broken and so is not usable >without shim-signed. Excuse me for asking a user question on -devel, but do we have any docs where someone explains how much a security trade off is shim-signed relativ to the optimum? I think that using shim-signed is surely worse than a directly signed kernel, but I don't know whether I can tell my system (or shim-signed?) to accept MY or Debian's signed kernel without the Microsoft intermediate signature, and whether this is any more secure than running an encrypted system without secure boot at all. Do we have docs for that? >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. >If not, is the problem having other blobs of data on the media that we >also cannot generate, or is it the licensing of that data, or something >else? 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. >If it ensures that fewer people abandon Debian out of frustration with >the install then I'd suggest that it will actually result in less >non-free software being used overall, as will having the option to >enable only non-free-firmware without also enabling non-free. Those are the people who use Ubuntu without even trying Debian because somebody told them that Debian is SO hard to install. 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
Bug#1010055: ITP: base16384 -- Encode binary file to printable utf16be, and vise versa.
Package: wnpp Severity: wishlist Owner: fumiama * Package name: base16384 Version : 2.2.0 Upstream Author : fumiama * URL : https://launchpad.net/base16384 * License : GPLv3 Programming Lang: C Description : Encode binary file to printable utf16be, and vise versa. We use 16384 Chinese characters (from \u4E00 to \u8DFF) as the "alphabet", just like what base64 did. If length of the data has a remainder after mod 7, we will use \u3Dxx to present it with xx ranging from 01 to 06. - I designed this base64-like algorithm and had published it to my lauchpad PPA https://code.launchpad.net/~fumiama/+archive/ubuntu/ppa It seems to work well so that I hope to see more people who can use this util easily by entering apt-get directly. - I have read the wiki and found that in order to pubish my package to Debian, I am requested to get a sponsor for it. So I will file a RFS bug report later.
Re: shim-signed (was: Firmware - what are we going to do about it?)
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? 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. 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. > 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. Ansgar
Re: Firmware - what are we going to do about it?
Op 19-04-2022 om 02:30 schreef Steve McIntyre: I see several possible options that the images team can choose from here. However, several of these options could undermine the principles of Debian. We don't want to make fundamental changes like that without the clear backing of the wider project. That's why I'm writing this... I have an idea for an extra option: 6. Put the closed source firmware somewhere in the Debian images, but never install closed source firmware by default. "No" should be the default. And to put "non-free" into sources.list should also be an non-default choice, even when you install closed source firmware. Maybe there could also be a patch, what removes the closed-source firmware from the image. With regards, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl
Bug#1010063: ITP: golang-github-mndrix-tap-go -- Test Anything Protocol for Go
Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler
* Package name: golang-github-mndrix-tap-go
Version : 0.0~git20171203.629fa40-1
Upstream Author : Michael Hendricks
* URL : https://github.com/mndrix/tap-go
* License : Public Domain
Programming Lang: Go
Description : Test Anything Protocol for Go
Test Anything Protocol for Go
.
The Test Anything Protocol (http://testanything.org/) ("TAP") is a text-
based interface between tests and a test harness. This package helps Go
to generate TAP output.
.
Read the full package documentation
(https://godoc.org/github.com/mndrix/tap-go)
I'm going be maintain this under the pkg-golang team umbrella
Build dependency for golang-github-opencontainers-runtime-tools
Re: Firmware - what are we going to do about it?
On Sat, Apr 23, 2022 at 03:13:29PM +0200, Paul van der Vlis wrote: > > I see several possible options that the images team can choose from here. > > However, several of these options could undermine the principles of Debian. > > We > > don't want to make fundamental changes like that without the clear backing > > of > > the wider project. That's why I'm writing this... > > I have an idea for an extra option: > > 6. Put the closed source firmware somewhere in the Debian images, but never > install closed source firmware by default. "No" should be the default. That's the option 3 more or less. > to put "non-free" into sources.list should also be an non-default choice, > even when you install closed source firmware. No, that's a bad idea, which is one of the main reasons for the option 5. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1010065: ITP: swagger-ui -- Swagger UI is a collection of HTML, JavaScript, and CSS assets that dynamically generate beautiful documentation from a Swagger-compliant API.
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: swagger-ui Version : 4.10.3 Upstream Author : Name * URL : https://github.com/swagger-api/swagger-ui * License : Apache-2.0 Programming Lang: Javsscript Description : generate beautiful documentation from a Swagger-compliant API Swagger UI allows anyone — be it your development team or your end consumers — to visualize and interact with the API’s resources without having any of the implementation logic in place. It’s automatically generated from your OpenAPI (formerly known as Swagger) Specification, with the visual documentation making it easy for back end implementation and client side consumption.
Re: shim-signed (was: Firmware - what are we going to do about it?)
Marc Haber wrote: >On Fri, 22 Apr 2022 11:16:42 +0200, Philip Hands >wrote: >>I understand the urge to insist upon absolute DFSG purity in the media >>we produce, but when it comes to wanting to avoid every last shred of >>data that we could not regenerate ourselves, I think we crossed that >>line some time ago. >> >>I'm thinking of shim-signed, which is included in our official media. >> >>Despite being free software in source form, it is signed by Microsoft, >>and can only be expected to work with that signature ... which we cannot >>create. >> >>On most (all?) hardware one is able to avoid UEFI secure-boot, so won't >>need to use shim-signed, but I'd imagine that some hardware insists on >>secure-boot, or the opt-outs are somehow broken and so is not usable >>without shim-signed. > >Excuse me for asking a user question on -devel, but do we have any >docs where someone explains how much a security trade off is >shim-signed relativ to the optimum? I think that using shim-signed is >surely worse than a directly signed kernel, but I don't know whether I >can tell my system (or shim-signed?) to accept MY or Debian's signed >kernel without the Microsoft intermediate signature, and whether this >is any more secure than running an encrypted system without secure >boot at all. 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. Fundamentally, shim is a compromise. It lets us use an existing root of trust (that's already installed on the vast majority of x86 machines) to bootstrap our own secure setup. If you don't like the fact that Microsoft's keys are involved. it's possible on a lot of machines to enrol your own keys and remove Microsoft's entirely. If you go that way, you could absolutely sign grub and/or the kernel directly. But that's not something that's easy to do - it's not likely to work well for the vast majority of users. Running an encrypted system without secure boot *at all* is a difficult thing to support well. The entire point of SB is that the firmware can use keys to validate the next stage in the boot process. An *encrypted* kernel stops other people logging in to your system, but it does not give you protection against somebody tampering with the system behind your back and doing a MitM attack. 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. ... >>If not, is the problem having other blobs of data on the media that we >>also cannot generate, or is it the licensing of that data, or something >>else? > >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. 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. -- 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: Re: Firmware - what are we going to do about it
Luca Boccassi wrote: > Personally, I'd even go for option 4, so that other drivers are covered > too (the general advice that can be found on the internet for users > with nvidia hardware seems to be: "avoid Debian, go Ubuntu/Mint/etc", > which is just a sad state of affairs). But option 5 is already a great > improvement upon the status quo. Agree! The original post did mention video cards, but I'm left unsure whether the non-free stuff in the NVidia case, for example, would fall into "firmware" (hence included) or "drivers". If the latter, my sense is that Option 5 was intended to be narrowly focused and exclude such drivers. I'd rather support a wider focus that would include drivers -- basically any "non-free hardware support package". So if Option 5 is narrow and Option 4 is wide-open "non- free" maybe there's room for an option in between? -Steve signature.asc Description: This is a digitally signed message part.
Re: Firmware - what are we going to do about it?
Op 23-04-2022 om 16:10 schreef Andrey Rahmatullin: On Sat, Apr 23, 2022 at 03:13:29PM +0200, Paul van der Vlis wrote: I see several possible options that the images team can choose from here. However, several of these options could undermine the principles of Debian. We don't want to make fundamental changes like that without the clear backing of the wider project. That's why I'm writing this... I have an idea for an extra option: 6. Put the closed source firmware somewhere in the Debian images, but never install closed source firmware by default. "No" should be the default. That's the option 3 more or less. Option 3 says to publish two sets of images. And it says nothing about defaults. 3. We could stop pretending that the non-free images are unofficial, and maybe move them alongside the normal free images so they're published together. This would make them easier to find for people that need them, but is likely to cause users to question why we still make any images without firmware if they're otherwise identical. to put "non-free" into sources.list should also be an non-default choice, even when you install closed source firmware. No, that's a bad idea, which is one of the main reasons for the option 5. The idea is not to promote closed source firmware in any way. Have it available, but only for the people who really want it. Maybe it's also an idea to put the firmware in a seperate partition. With regards, Paul BTW: I sell Debian media like USB-sticks. I know about the problems people have to choose a medium-type etc. -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl
Re: Firmware - what are we going to do about it?
On 2022-04-23 22:48:03, Paul van der Vlis wrote: > Op 23-04-2022 om 16:10 schreef Andrey Rahmatullin: > > On Sat, Apr 23, 2022 at 03:13:29PM +0200, Paul van der Vlis wrote: > > > > I see several possible options that the images team can choose from > > > > here. > > > > However, several of these options could undermine the principles of > > > > Debian. We > > > > don't want to make fundamental changes like that without the clear > > > > backing of > > > > the wider project. That's why I'm writing this... > > > > > > I have an idea for an extra option: > > > > > > 6. Put the closed source firmware somewhere in the Debian images, but > > > never > > > install closed source firmware by default. "No" should be the default. > > That's the option 3 more or less. > > Option 3 says to publish two sets of images. > And it says nothing about defaults. > > > 3. We could stop pretending that the non-free images are unofficial, and > maybe move them alongside the normal free images so they're published > together. This would make them easier to find for people that need them, but > is likely to cause users to question why we still make any images without > firmware if they're otherwise identical. > > > > > to put "non-free" into sources.list should also be an non-default choice, > > > even when you install closed source firmware. > > No, that's a bad idea, which is one of the main reasons for the option 5. > > The idea is not to promote closed source firmware in any way. Have it > available, but only for the people who really want it. Uh. Have you actually read the start of the thread? Most machines nowadays *need* it. It's not about wanting, but about the fact that firmware is needed, and the more barriers you put in front of people, the more people will just go with Ubuntu or other alternatives. Making Debian hard to use is a very short-sighted view of how to promote free software - it works in the very short term only. regards, iustin
Re: Firmware - what are we going to do about it?
On Sat, Apr 23, 2022 at 4:50 PM Paul van der Vlis wrote: > Op 23-04-2022 om 16:10 schreef Andrey Rahmatullin: > > On Sat, Apr 23, 2022 at 03:13:29PM +0200, Paul van der Vlis wrote: > >>> I see several possible options that the images team can choose from > here. > >>> However, several of these options could undermine the principles of > Debian. We > >>> don't want to make fundamental changes like that without the clear > backing of > >>> the wider project. That's why I'm writing this... > >> > >> I have an idea for an extra option: > >> > >> 6. Put the closed source firmware somewhere in the Debian images, but > never > >> install closed source firmware by default. "No" should be the default. > > That's the option 3 more or less. > > Option 3 says to publish two sets of images. > And it says nothing about defaults. > > > 3. We could stop pretending that the non-free images are unofficial, and > maybe move them alongside the normal free images so they're published > together. This would make them easier to find for people that need them, > but is likely to cause users to question why we still make any images > without firmware if they're otherwise identical. > > This is the option I like. As a user who needs the closed source binary blobs they should be easier to find. > >> to put "non-free" into sources.list should also be an non-default > choice, > >> even when you install closed source firmware. > > No, that's a bad idea, which is one of the main reasons for the option 5. > > The idea is not to promote closed source firmware in any way. Have it > available, but only for the people who really want it. > > Maybe it's also an idea to put the firmware in a seperate partition. > > With regards, > Paul > > BTW: I sell Debian media like USB-sticks. I know about the problems > people have to choose a medium-type etc. > > > -- > Paul van der Vlis Linux systeembeheer Groningen > https://vandervlis.nl > >
Re: Firmware - what are we going to do about it?
On Sat, Apr 23, 2022 at 10:48:03PM +0200, Paul van der Vlis wrote: > > > I have an idea for an extra option: > > > > > > 6. Put the closed source firmware somewhere in the Debian images, but > > > never > > > install closed source firmware by default. "No" should be the default. > > That's the option 3 more or less. > > Option 3 says to publish two sets of images. > > > 3. We could stop pretending that the non-free images are unofficial, and > maybe move them alongside the normal free images so they're published > together. This would make them easier to find for people that need them, but > is likely to cause users to question why we still make any images without > firmware if they're otherwise identical. > If you want to drop the non-firmware image then it's the option 4 more or less. > And it says nothing about defaults. d-i defaults are mostly unrelated to the ISO set and the archive setup questions. You seem to want to add a yet another "free vs usable, with free as the default" question, which is not too bad, just yet another thing for most people to change. > > > to put "non-free" into sources.list should also be an non-default choice, > > > even when you install closed source firmware. > > No, that's a bad idea, which is one of the main reasons for the option 5. > > The idea is not to promote closed source firmware in any way. Have it > available, but only for the people who really want it. *shrug* that's just "have it available for most people" with extra complexity. And you seem to miss the problem with installing firmware packages but not enabling updates for them. -- WBR, wRAR signature.asc Description: PGP signature
Re: secnet_0.6.2_multi.changes REJECTED
Hello,
On Mon 11 Apr 2022 at 05:51PM +01, Ian Jackson wrote:
>> They also pointed out that there is some code from StackOverflow,
>> which is not GPL-3+.
>
> I think this is not right? I think you are referring to
> `argparseactionnoyes.py`. As I documented in the file header, it is
> part of StackOverflow's TOS that contributors grant a CC-BY-SA 4.0
> licence for the snippets they upload, which would make the
> contributions GPL3+-compatible. My file comment gives the relevant
> references. [1]
>
> It seems to me that StackOverflow have chosen this approach (making
> the upload licence part of the TOS) precisely to enable people to copy
> code fragments out of StackOverflow into their own projects. ISTM
> that in (unless it appears that the posting StackOverflow user did not
> write the code in question), we should be able to rely on that.
>
> Can you please confirm whether the opinion of the ftpmaster team, that
> is not sufficient? If it is not sufficent, I guess I will find
> someone to write a clean room implementation of this 22-line class.
In this case, I believe I was just passing on the other team member's
comment. What you say seems fine, though it should be documented in
d/copyright -- the code does not become GPL-3+ by being GPL-3-compatible.
>> I noticed that b91dec.{php,awk} have no license information at all.
>
> As you observe, these files as provided by upstream do not themselves
> contain licence information. But the file base91-c/README (which is
> provided by upstream) says, amongst other things:
>
> All source code in this package is released under the terms of the BSD
> license.
> See the file LICENSE for copying permission.
>
> And these files were (according to their copyright notice) written by
> the same author and clearly part of the base91-c project. I think
> this licence therefore applies also to the files b91dec.{php,awk}.
Sounds like I was just being confused by directory structure, then.
>> Shouldn't subdirmk be a separate package?
>
> Well. It is designed to be "git-subtree"'d into one's package. That
> is the way the upstream package uses it.
>
> It would be possible to make it a separate package and build-depend on
> it, at the cost of some additional work. The upside would be a very
> small amount of disk space saving, and largely theoretical saving of
> work in case of a need to do a security update for subdirmk (which
> seems unlikely to be critical since it's build system software which
> is designed to execute its input) - and that all only in the case
> where a second package in Debian uses subdirmk.
>
> It seemed me best to me to defer this work until subdirmk becomes more
> widely used.
Cool. Just wanted to raise the question.
--
Sean Whitton
signature.asc
Description: PGP signature
Re: Firmware - what are we going to do about it
Steven Robbins wrote: > >Luca Boccassi wrote: > >> Personally, I'd even go for option 4, so that other drivers are covered >> too (the general advice that can be found on the internet for users >> with nvidia hardware seems to be: "avoid Debian, go Ubuntu/Mint/etc", >> which is just a sad state of affairs). But option 5 is already a great >> improvement upon the status quo. > >Agree! > >The original post did mention video cards, but I'm left unsure whether the >non-free stuff in the NVidia case, for example, would fall into "firmware" >(hence included) or "drivers". If the latter, my sense is that Option 5 was >intended to be narrowly focused and exclude such drivers. I'd rather support >a wider focus that would include drivers -- basically any "non-free hardware >support package". So if Option 5 is narrow and Option 4 is wide-open "non- >free" maybe there's room for an option in between? I have no desire to add a wider set of packages from non-free onto our media, I'm afraid. I'm entirely focused on firmware and **not** drivers. As and when we start to draft a GR to formalise what the project wants, feel free to add an option for that too but I personally wouldn't expect it to gain much traction. -- 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 Sat, 2022-04-23 at 18:21 +0100, Steve McIntyre wrote: > If you don't like the fact that Microsoft's keys are involved, > it's possible on a lot of machines to enrol your own keys On machines where this isn't possible in the UEFI firmware interface, IIRC shim-signed is designed to allow you to enrol your own keys; you should be able to boot Debian's MS-signed shim-signed once, enrol your own keys and then switch to your own shim-signed. If UEFI bugs prevent loading your own shim-signed, then Debian's MS-signed shim-signed will still let you replace the Debian-signed GRUB, Linux etc images. IIRC this was done so that the distro docs can ignore the UEFI firmware user interface for enrolling keys, which is different for every UEFI vendor, while the shim interface for this is the same everywhere. Of course, there may be UEFI bugs that break some of this, and on ARM the MS requirement to allow enrolling keys was initially not present, not sure if they re-added it for recent ARM based Windows laptops. > and remove Microsoft's entirely. ISTR that I read that even if you can do this on your particular UEFI firmware, in practice this often *isn't* possible because parts of the pre-installed firmware for some devices (option ROMs?) are MS-signed. > we could even offer our own different shim-signed package to match. Renaming shim-signed to shim-signed-microsoft and adding a new package shim-signed-debian sounds like a good idea to me. > If we had a large enough number of users wanting a different root of trust I've seen a few people over the years wanting this, most want their own root of trust rather a Debian root of trust though. There probably aren't enough people to justify the extra effort, but it would make Debian useful in a few more use-cases. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Firmware - what are we going to do about it?
Hi, On 4/23/22 11:07 PM, Iustin Pop wrote: Making Debian hard to use is a very short-sighted view of how to promote free software - it works in the very short term only. The same applies in the other direction -- making no real distinction between free and non-free software is a short term solution to the usability problem, but does not incentivize hardware vendors to open up designs in the slightest. With drivers, user awareness is there at least. People know that the nV drivers are essentially unsupported and if it breaks, they get to keep the pieces. The same isn't true for firmware, users just expect that stuff will work and if it doesn't, it's Debian's fault. We can either validate that expectation, or push back on it, saying "this hardware is supported on a best-effort basis, but we can't help you because it's closed source." Simon
Re: shim-signed
]] Marc Haber > Excuse me for asking a user question on -devel, but do we have any > docs where someone explains how much a security trade off is > shim-signed relativ to the optimum? I think that using shim-signed is > surely worse than a directly signed kernel, but I don't know whether I > can tell my system (or shim-signed?) to accept MY or Debian's signed > kernel without the Microsoft intermediate signature, and whether this > is any more secure than running an encrypted system without secure > boot at all. > > Do we have docs for that? I don't think we have docs for running with a different root of trust than MS'. To be honest, I'm not sure we even _should_ have a lot of docs around it, since the general brittleness of the boot process, UEFI and friends might very well lead to more systems being broken when people discover the docs and run with the instructions without understanding the implications. As for it being more secure, for that to be a good and meaningful discussion, we have to agree on what the threat model is. What's the threat you want to protect against by using your own or Debian's keys? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
