Re: [gentoo-dev] Re: linux-firmware
On Tue, Feb 19, 2013 at 11:55 PM, Ulrich Mueller u...@gentoo.org wrote: On Tue, 19 Feb 2013, Alec Warner wrote: Lets not re-invent the wheel here: Debian has free and non-free packages. http://packages.debian.org/sid/firmware-linux # free copyright http://packages.debian.org/changelogs/pool/main/f/firmware-free/firmware-free_3.2/firmware-linux-free.copyright # nonfree copyright http://packages.debian.org/changelogs/pool/non-free/f/firmware-nonfree/firmware-nonfree_0.36+wheezy.1/firmware-linux-nonfree.copyright http://pkgs.fedoraproject.org/cgit/linux-firmware.git/tree/linux-firmware.spec Specifically: License: GPL+ and GPLv2+ and MIT and Redistributable, no modification permitted It looks like OpenSuse has split packages. Most distros are debian or redhat based these days. We can easily have a firmware package that is USE=nonfree and only install the libre firmware, ala debian. This also fixes 'the license issue' because if people want ACCEPT_LICENSE=@OSI-APPROVED they just need to turn the nonfree flag off. None of this is rocket science, and the work has likely already been done by others, so just take it and go. I mostly agree. However, there are not two, but three classes of licenses for firmware images: 1. Free software 2. Non-free, but can be redistributed 3. Cannot be redistributed The split between 2 and 3 is the more important one, because we cannot mirror things under 3. Have we talked to debian then? Nominally if we can't dist it, they can't dist it (and vice versa.) -A Ulrich
Re: [gentoo-dev] Re: linux-firmware
Duncan wrote: Is it possible to tell git to only clone/pull specific files in a repo? No. //Peter
Re: [gentoo-dev] Re: linux-firmware
On Wed, 20 Feb 2013, Alec Warner wrote: On Tue, Feb 19, 2013 at 11:55 PM, Ulrich Mueller u...@gentoo.org wrote: I mostly agree. However, there are not two, but three classes of licenses for firmware images: 1. Free software 2. Non-free, but can be redistributed 3. Cannot be redistributed The split between 2 and 3 is the more important one, because we cannot mirror things under 3. Have we talked to debian then? Nominally if we can't dist it, they can't dist it (and vice versa.) From a quick glance at their tarball it seems that they exclude some firmware images that are included in our tarball. For example, I don't see atmsar11.fw and k1212.dsp (first two entries in WHENCE) in their tarball. Which makes sense because both are not redistributable. Ulrich
Re: [gentoo-dev] Re: linux-firmware
On Tue, Feb 19, 2013 at 11:43 PM, Duncan 1i5t5.dun...@cox.net wrote: If all upstream has is a git tarball, what about git-snapshot builds? Use the git2 eclass and set a commit number, thus allowing testing and stabilization of a specific commit, but the checkout would be directly from upstream, so (for the general case, live-image case discussed below) gentoo wouldn't be distributing anything but the ebuild. There is a current QA policy that anything using an scm to download sources cannot be stabilized, because there is no way to verify the manifest. I'm actually wondering if that makes sense with git when a specific commit is referenced, since everything is content-hashed anyway. Perhaps we just need to confirm that git actually checks the hash. Rich
Re: [gentoo-dev] Re: linux-firmware
2013/2/20 Rich Freeman ri...@gentoo.org: There is a current QA policy that anything using an scm to download sources cannot be stabilized, because there is no way to verify the manifest. I'm actually wondering if that makes sense with git when a specific commit is referenced, since everything is content-hashed anyway. Perhaps we just need to confirm that git actually checks the hash. If you checkout some revision or tag just create the darn tarball yourself as it is much cleaner solution and you don't force user to install git or other scm tools unless they need them.
Re: [gentoo-dev] Re: linux-firmware
On 20/02/2013 13:02, Rich Freeman wrote: I'm actually wondering if that makes sense with git when a specific commit is referenced, since everything is content-hashed anyway. Perhaps we just need to confirm that git actually checks the hash. No. The policy is not _just_ because of the manifest verification. The policy is also because any ebuild relying on a network service to work cannot be assured to work at any point in time: not only it depends on the network connection of the user, but it also depends on the service to be available. So don't even _think_ about trying to ask for an exception for Git, because you'll have to have it over my ssh key. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: linux-firmware
Tomáš Chvátal schrieb: 2013/2/20 Rich Freeman ri...@gentoo.org: There is a current QA policy that anything using an scm to download sources cannot be stabilized, because there is no way to verify the manifest. I'm actually wondering if that makes sense with git when a specific commit is referenced, since everything is content-hashed anyway. Perhaps we just need to confirm that git actually checks the hash. If you checkout some revision or tag just create the darn tarball yourself as it is much cleaner solution and you don't force user to install git or other scm tools unless they need them. Problem is that the tarball cannot be redistributed by us. Now what? Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: linux-firmware
On 20/02/2013 14:29, Chí-Thanh Christopher Nguyễn wrote: Problem is that the tarball cannot be redistributed by us. Now what? Now you drop the firmwares that we can't distribute, and make the same tarball — as for those firmware... hash them separately and fetch-restrict them. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: linux-firmware
On Wed, Feb 20, 2013 at 8:17 AM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 20/02/2013 13:02, Rich Freeman wrote: I'm actually wondering if that makes sense with git when a specific commit is referenced, since everything is content-hashed anyway. Perhaps we just need to confirm that git actually checks the hash. The policy is also because any ebuild relying on a network service to work cannot be assured to work at any point in time: not only it depends on the network connection of the user, but it also depends on the service to be available. Makes sense in general. If there really are firmware blobs that are only available via git and which cannot be redistributed we might consider whether it makes sense to not support them entirely, or to force them to be masked. Dropping or masking the packages doesn't fix the fact that they require a network service to install - it just makes it harder to install the package. If a tarball exists or can be created that would be the best solution all-around, of course. Rich
Re: [gentoo-dev] Re: linux-firmware
On 20/02/2013 17:03, Rich Freeman wrote: Dropping or masking the packages doesn't fix the fact that they require a network service to install - it just makes it harder to install the package. The reason why they are masked is because users who want to use a live ebuild will acknowledge that they know it might not install at all. No, we're not going to change this policy, so don't even suggest it -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: linux-firmware
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/20/2013 02:55 AM, Ulrich Mueller wrote: I am going to respond here because it makes the most sense to me. I mostly agree. However, there are not two, but three classes of licenses for firmware images: 1. Free software 2. Non-free, but can be redistributed 3. Cannot be redistributed The split between 2 and 3 is the more important one, because we cannot mirror things under 3. I completely agree. I will HAPPILY divide the ebuild up with a nonfree (or other suggested SANE use flag) to denote the difference between 1 and 2. None of this is under contest, this choice is all but too easy. Depending on the licensing issues which arise I may even add in a separate ebuild. The issue come in with number 3. Adding a bindist use flag for the - - ebuild seems sane since it pulls from git and we don't have to redist it, but is is possible to RESTRICT=bindist? bindist ? Anyone volunteering to tear through this licensing mess and start breaking things into groups? - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRJPedAAoJEKXdFCfdEflKhIUQAKXMr8tpwhrFBh2/LxfsdVRQ n6F72a2KCHyM2YCCQsw3eKskBKmeawQNNKWAQmOaDjn6dcEVi0hxHBLr42m3CZiL yNA9PRAvRSyshEn8NN/ExTR4eGZft2XqPuhszN129Eu3pJknvKQaPy5ItNzORzN0 FJDherBc2DXs4Uc0VmKxezHxNZZwv1OHIRPtNFGTDy4Eixw4GCYOEg8u1yI23iz7 p+Ef2YjoJPqs9Q3zxuFuJ/is9tIcKdzRy7kNXne92BCvVIst5Dflgg6kQ925eoaM RifTXv6w1cinItrBRzITftS6j44CcZVpYyRye1ganwuLb90Cxb5U2x8wsj6a1Tcu okVMWk/ncAHvjrkVoC1/wSpjyCgL5J2EaY5C5O5kkhPxNhwjfICpppawGR7psxAJ EQjl+u8O6HlVVbPIHTKGlEtSG+HGxVrVX5+CNj39MHEVIhqqVkvw+UenG4lG/Dv8 T+uAjTMYXJzMcVcw90hg8vHmygjXDwIypf0VGf4h+RCloX92dCP5HeBaU79/18Gz cGfdnOlSsUG7dr+VG4g7O+4AsopNbRe+a2EugGSMQ5IjkK7TaCYFt7K0nKbVYVyt AeMhsU17/X15rUpYNv37Liu4ythXyldVQMpnvclbx/kwiPR1bK3XSZfvZOX0g5Rb E2snaN0NNWWCIoj4aK1r =BJk0 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: linux-firmware
Diego Elio Pettenò wrote: The policy is also because any ebuild relying on a network service to work cannot be assured to work at any point in time While noble, I think it is a bit naïve. Reality is that many if not most ebuilds *anyway* rely on temporal things - such as a current enough versions of portage, or a new enough profile, or tar and sed. Requiring git and a network connection is the restriction imposed by the copyright holder. There's really no way around that. depends on the network connection of the user, but it also depends on the service to be available. Right, because those files can only be legally distributed by the service on the network. No matter how much you and I think that sucks, it is still the only way for the user to get that file. It makes no sense to make that unneccessarily difficult for users. So don't even _think_ about trying to ask for an exception for Git, because you'll have to have it over my ssh key. This is just trying to be a bully and acting like a drama queen, which does nothing but make you look super silly, and that seems completely unneccessary. If you dislike something then you should express that in a more mature manner so that people can actually take you seriously. When you behave badly like this you just end up getting bad behavior, spite and disrespect in return, even if it takes a while to reach you. //Peter
Re: [gentoo-dev] Re: linux-firmware
On 20/02/2013 17:28, Peter Stuge wrote: This is just trying to be a bully and acting like a drama queen, which does nothing but make you look super silly, and that seems completely unneccessary. If you dislike something then you should express that in a more mature manner so that people can actually take you seriously. When you behave badly like this you just end up getting bad behavior, spite and disrespect in return, even if it takes a while to reach you. Peter, I'll ask simply, and politely: stop being a nuisance, especially since you can't be bothered to become a developer (not that I would like to have you among the developers, honestly; I'd gladly take a few more mgornys beside you). This policy has been around for a very long time, and will be kept around. It's not going to change, because it makes no sense for it to change. It might be inconvenient to _you_, but once again, we're not here to do stuff only when it's convenient. So, please, really please, stop thinking like whatever your experience is, that's the only experience out there. Between you and Rich, I think you've been voicing your opinion just because you can, and without thinking about repercussion for others, under the principle that the incumbent is always wrong. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: linux-firmware
On Wed, 20 Feb 2013, Rick \Zero Chaos\ Farina wrote: On 02/20/2013 02:55 AM, Ulrich Mueller wrote: I am going to respond here because it makes the most sense to me. I mostly agree. However, there are not two, but three classes of licenses for firmware images: 1. Free software 2. Non-free, but can be redistributed 3. Cannot be redistributed The split between 2 and 3 is the more important one, because we cannot mirror things under 3. I completely agree. I will HAPPILY divide the ebuild up with a nonfree (or other suggested SANE use flag) to denote the difference between 1 and 2. None of this is under contest, this choice is all but too easy. Depending on the licensing issues which arise I may even add in a separate ebuild. The issue come in with number 3. Adding a bindist use flag for the - - ebuild seems sane since it pulls from git and we don't have to redist it, but is is possible to RESTRICT=bindist? bindist ? Eh, what? You want to exclude the non-redistributable firmware from binpkgs build by the user? I.e. USE=-bindist would include everything but USE=bindist wouldn't? IIUC, you don't need an additional RESTRICT then. Anyone volunteering to tear through this licensing mess and start breaking things into groups? Does the WHENCE cover everything that is currently included in your tarball? Ulrich
Re: [gentoo-dev] Re: linux-firmware
On Wed, Feb 20, 2013 at 8:28 AM, Peter Stuge pe...@stuge.se wrote: Diego Elio Pettenò wrote: The policy is also because any ebuild relying on a network service to work cannot be assured to work at any point in time While noble, I think it is a bit naïve. Reality is that many if not most ebuilds *anyway* rely on temporal things - such as a current enough versions of portage, or a new enough profile, or tar and sed. These are things that we have covered, generally speaking. @system will bring in tar and sed, and a minimum version of portage. Old profiles are tagged as deprecated, and users are encouraged to migrate to current profiles. The PMS defines which bits the ebuilds can use, and if a program needs a 'newer' sed, it should say so in its dependencies. We could add something like PROPERTIES=network to packages that require the network. I'm vaguely sure for instance, that some src_test() phases require a functioning network to work properly. Requiring git and a network connection is the restriction imposed by the copyright holder. There's really no way around that. I'm confused though, we can easily just make 2 ebuilds. linux-firmware[non-free] - the use flag to toggle between free and non-free licenses. linux-firmware-noredist - This one is RESTRICT=fetch mirror RESTRICT=fetch mirror already exists, has existed for years, and exists for exactly this purpose. depends on the network connection of the user, but it also depends on the service to be available. Right, because those files can only be legally distributed by the service on the network. No matter how much you and I think that sucks, it is still the only way for the user to get that file. It makes no sense to make that unneccessarily difficult for users. I don't think fetch restriction is that annoying. You could argue that we do it debian / ubuntu style where the files are fetched in a postinstall, but I think that is sort of hacky myself. So don't even _think_ about trying to ask for an exception for Git, because you'll have to have it over my ssh key. This is just trying to be a bully and acting like a drama queen, which does nothing but make you look super silly, and that seems completely unneccessary. If you dislike something then you should express that in a more mature manner so that people can actually take you seriously. When you behave badly like this you just end up getting bad behavior, spite and disrespect in return, even if it takes a while to reach you. //Peter
Re: [gentoo-dev] Re: linux-firmware
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/20/2013 11:44 AM, Ulrich Mueller wrote: On Wed, 20 Feb 2013, Rick \Zero Chaos\ Farina wrote: On 02/20/2013 02:55 AM, Ulrich Mueller wrote: I am going to respond here because it makes the most sense to me. I mostly agree. However, there are not two, but three classes of licenses for firmware images: 1. Free software 2. Non-free, but can be redistributed 3. Cannot be redistributed The split between 2 and 3 is the more important one, because we cannot mirror things under 3. I completely agree. I will HAPPILY divide the ebuild up with a nonfree (or other suggested SANE use flag) to denote the difference between 1 and 2. None of this is under contest, this choice is all but too easy. Depending on the licensing issues which arise I may even add in a separate ebuild. The issue come in with number 3. Adding a bindist use flag for the - - ebuild seems sane since it pulls from git and we don't have to redist it, but is is possible to RESTRICT=bindist? bindist ? Eh, what? You want to exclude the non-redistributable firmware from binpkgs build by the user? I.e. USE=-bindist would include everything but USE=bindist wouldn't? IIUC, you don't need an additional RESTRICT then. So RESTRICT=bindist is only needed when there is no flag? Still I suppose it will come up if we break this into three parts. Anyone volunteering to tear through this licensing mess and start breaking things into groups? Does the WHENCE cover everything that is currently included in your tarball? The tarball is a full copy of the git tree so I'm going to say no. - -ZC -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRJP89AAoJEKXdFCfdEflKI3AP/33BKxpQA+lYGVcLTALhBsje ubxIcc6s3bo97O3XBaAxYOKTkb0SS8LGS4jCGN4m/IgMycqPZrkVTCruSq1SpRJ6 4thkLsLNsYr+niUQUt/QFoDRwzeWiFrToECXrJB7cPl0s8/TcGTxyke+rGeRjOVr TmKMEZB790mgjyTrSD4ZJkww3Czf1B370RDgNviN6LseiGXS0Il5Tuv8FouGFBFS cfyvVN/1RhQW8ANb9Dd+AzGhYdR8gNWUxFypVJSvM40n61BnOJ1RgfOqPKxv1RjD hvu5oDVBO7fSrT3iY3Cw5t70RS46lptJ7WE6wiRRP0KmvLyv+zimmdSs/4URpTZQ SXVhmBkRlRRLt6NKkg2Ok92F87uzu/eFFA4cUh+/sJazdRyY69JXRRl5/UbOeq8f 62MQJRiDbBGIDIDSKl01KyQ9oPba9+HNbakaTUYqB4bRvc5+0iJ0cmheThcFooCm PHpvWzkSxe5pIrs9Qk4c2eVRsrG8xl0mx+xsSRMv2nheYCFfJUnOy9pvs2p3Hk8e P3f7zN/WP7C/RvUDHBe8CAuNMuDDYT1c0PY6Kh1cKcWbNDn2tdq/Xat1kUiuOJQX k1vgEQdgrMR0VSmxi6aa909rWx4kqUh4P8MyOrDChaHGV/7v3PSrJha35vc9E/ls QZ8ZjHumELOrJ21lz7G1 =5Rzv -END PGP SIGNATURE-
Re: [gentoo-dev] Re: linux-firmware
On 20/02/2013 17:45, Alec Warner wrote: We could add something like PROPERTIES=network to packages that require the network. I'm vaguely sure for instance, that some src_test() phases require a functioning network to work properly. This has been proposed a bunch of times before, and I still wish to see it implemented. On the other hand, even for those that currently require network for src_test, if there was a quick opt-out, I foresee trouble: quite a few times it's possible to test 90% (figurative number) of a library without network, you just need to take the time to disable the network-bound tests (eventually giving upstream a patch to enable/disable the network side, or to ignore network failures instead of consider them a FAIL — versus getting the wrong response which _is_ a FAIL). Having non-masked ebuilds rely on network access also makes it extremely hard to do things such as isolated builds (for embedded/firmware-style OSes), and by experience would make the whole tinderboxing effort nearly unfeasible — for sure I would shut down both the tinderboxes as I'd be debugging network issues more often than actual problems with tinderbox/packages. linux-firmware[non-free] - the use flag to toggle between free and non-free licenses. linux-firmware-noredist - This one is RESTRICT=fetch mirror +1 — It requires some work from someone to actually split the stuff manually though, and there is at least one problem: somebody _got_ to redist the firmware for it to be fetched.. unless. But yes, the first obvious solution is, when snapshotting the repository, to just drop the noredist files, and add the above-suggested USE flag for the non-free ones. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Tue, Feb 19, 2013 at 10:32:13PM -0800, Alec Warner wrote: I agree that a smartcard is much better security vs a longer key. I don't think attackers targetting Gentoo are going to brute force the key. They are going to steal the key, trivially, by exploiting a 0-day in a crappy browser, or flash, or java, or whatever. A smartcard is the defense against this attack (because the key material is well protected, and they need physical access to actually relocate it.) Storing it in the TPM would also be cool, except TPMs are crap on Linux, *and* most hardware TPMs are crap anyway. Exactly. The longer key doesn't block this attack, the smartcard does. The question being asked becomes: If the smartcard only supports a shorter key is that an acceptable tradeoff where a longer key would be used instead? I say it's a very acceptable tradeoff, and the require/recommend of the proposal reflects this. Also, if there is a Well-Funded-Organization attacking Gentoo, there are MUCH more effective ways for them to compromise us. Any perceived gains in that field from requiring DSA2048 and blocking DSA1024 should be examined very closely. I would ask the opposite question. What is the perceived difficulty in using DSA2048 vs 1024? For the non-smartcard users, the cost is likely trivial. Even your perf data shows that signing requests still complete in 200ms or less, and that is on old / slow hardware. This is why I recommended DSA2048, but only required DSA1024. I don't want something that says If you use a smartcard, you can use DSA1024, otherwise you must use DSA2048 That's just too confusing. djm works for Google, and I chat with him at least once a quarter. I've seen some patches go by that we could re-purpose for gpg-agent forwarding. For slow machines we could have them sign on a faster-trusted machine with a forwarded agent. Major +1 on gpg-agent forwarding request; the smartcard crowd would love it too. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Re: linux-firmware
On Wed, Feb 20, 2013 at 11:45 AM, Alec Warner anta...@gentoo.org wrote: On Wed, Feb 20, 2013 at 8:28 AM, Peter Stuge pe...@stuge.se wrote: It makes no sense to make that unneccessarily difficult for users. I don't think fetch restriction is that annoying. You could argue that we do it debian / ubuntu style where the files are fetched in a postinstall, but I think that is sort of hacky myself. The concern wasn't with fetch restrictions so much as with masking. Fetch restriction works if upstream provides a tarball but we can't redistribute it. If upstream doesn't provide a tarball and we can't redistribute anything, then a live scm ebuild is the only way to deploy something, and current policy is that these must be masked. I do understand Diego's concerns with some edge cases, including the tinderbox. Some kind of PROPERTIES=network solution might be the best compromise. Until then masking things is better than dropping them. It just doesn't seem ideal to have packages that are basically permanently masked. Masking is usually a temporary solution for testing or removal, or it can be applied to things like live ebuilds which are moving targets that can never have QA. I think the fact that we have to resort to masking in this case is more a reflection of a limitation of portage, but saying so doesn't fix anything, so we'll just have to live with it for now... Since this topic came up elsewhere in the thread it really isn't my goal to cause inconvenience or debate things imply for their own sake. I just would like to see things improve when it is possible, and don't tend to censor my questions as a result. I don't really disagree with the status quo simply because it is the status quo. I think that is more selection bias - when I agree with the status quo I'm less likely to post anything at all... Rich
Re: [gentoo-dev] Re: linux-firmware
On Wed, Feb 20, 2013 at 9:17 AM, Rich Freeman ri...@gentoo.org wrote: On Wed, Feb 20, 2013 at 11:45 AM, Alec Warner anta...@gentoo.org wrote: On Wed, Feb 20, 2013 at 8:28 AM, Peter Stuge pe...@stuge.se wrote: It makes no sense to make that unneccessarily difficult for users. I don't think fetch restriction is that annoying. You could argue that we do it debian / ubuntu style where the files are fetched in a postinstall, but I think that is sort of hacky myself. The concern wasn't with fetch restrictions so much as with masking. Fetch restriction works if upstream provides a tarball but we can't redistribute it. If upstream doesn't provide a tarball and we can't redistribute anything, then a live scm ebuild is the only way to deploy something, and current policy is that these must be masked. Not following you here. We cannot redistribute dev-java/sun-j2ee for instance. We don't mirror dev-java/sun-j2ee. We tell the user 'hey go download j2ee from Oracle and put it in $LOCATION. A live SCM ebuild is not the only way to deploy something. If the user has to go download a blob out of linux-firmware's gitweb because we feel we cannot legally distribute the firmware, then that is what they have to do. If the user has to go to the manufacturers website to get the firmware, then that is what they have to do. I do understand Diego's concerns with some edge cases, including the tinderbox. Some kind of PROPERTIES=network solution might be the best compromise. Until then masking things is better than dropping them. It just doesn't seem ideal to have packages that are basically permanently masked. Masking is usually a temporary solution for testing or removal, or it can be applied to things like live ebuilds which are moving targets that can never have QA. I think the fact that we have to resort to masking in this case is more a reflection of a limitation of portage, but saying so doesn't fix anything, so we'll just have to live with it for now... Since this topic came up elsewhere in the thread it really isn't my goal to cause inconvenience or debate things imply for their own sake. I just would like to see things improve when it is possible, and don't tend to censor my questions as a result. I don't really disagree with the status quo simply because it is the status quo. I think that is more selection bias - when I agree with the status quo I'm less likely to post anything at all... Rich
Re: [gentoo-dev] Re: linux-firmware
On Wed, Feb 20, 2013 at 12:25 PM, Alec Warner anta...@gentoo.org wrote: A live SCM ebuild is not the only way to deploy something. If the user has to go download a blob out of linux-firmware's gitweb because we feel we cannot legally distribute the firmware, then that is what they have to do. If the user has to go to the manufacturers website to get the firmware, then that is what they have to do. Agreed, especially if only 1-2 files are involved. If it is a bunch that could get unwieldy. Wasn't really thinking about that option. Rich
Re: [gentoo-dev] Re: linux-firmware
On 20/02/2013 18:28, Rich Freeman wrote: Agreed, especially if only 1-2 files are involved. If it is a bunch that could get unwieldy. Wasn't really thinking about that option. That being the case, splitting them in multiple packages might indeed be a better option. Yes I know I'm the one pushing for using a single package — as long as it doesn't have licensing issues of course. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: linux-firmware
On Wed, Feb 20, 2013 at 12:32 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: That being the case, splitting them in multiple packages might indeed be a better option. Yes I know I'm the one pushing for using a single package — as long as it doesn't have licensing issues of course. Yup, a combined package that is fetch-restricted with 57 files in the SRC_URI isn't really something that anybody would like. Probably makes sense to have a few tiers: 1. Free 2. Non-free, but redistributable 3. Non-free, nonredistributable, but fetchable (maybe combine with #2) 4. Non-fetchable - do not combine. Rich
Re: [gentoo-dev] Re: linux-firmware
On Wed, Feb 20, 2013 at 11:03:47AM -0500, Rich Freeman wrote: On Wed, Feb 20, 2013 at 8:17 AM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 20/02/2013 13:02, Rich Freeman wrote: I'm actually wondering if that makes sense with git when a specific commit is referenced, since everything is content-hashed anyway. Perhaps we just need to confirm that git actually checks the hash. The policy is also because any ebuild relying on a network service to work cannot be assured to work at any point in time: not only it depends on the network connection of the user, but it also depends on the service to be available. Makes sense in general. If there really are firmware blobs that are only available via git and which cannot be redistributed we might consider whether it makes sense to not support them entirely, or to force them to be masked. Did anyone actually consider the fact that there should not be non-redistributable firmware blobs in the upstream git tree in the first place, as it is the thing that is doing the redistributing originally? Has anyone pointed out any problems with the package to upstream if you have found them? If so, what did they say? greg k-h
Re: [gentoo-dev] Re: linux-firmware
Greg KH wrote: If there really are firmware blobs that are only available via git and which cannot be redistributed we might consider whether it makes sense to not support them entirely, or to force them to be masked. Did anyone actually consider the fact that there should not be non-redistributable firmware blobs in the upstream git tree in the first place, as it is the thing that is doing the redistributing originally? I think non-redistributable in this case means by Gentoo since that was identified to be the case for some of the files in the git repository. Their license allows them to be distributed in linux-firmware.git, but not elsewhere. //Peter
Re: [gentoo-dev] RFC: Gentoo GPG key policies
RHJ == Robin H Johnson robb...@gentoo.org writes: RHJ 2. Root key type of RSA, 4096 bits rsa 4k provides no real benefits over rsa 3k here; it is just slower for everyone, signing or verifying. Cf, eg, http://www.nsa.gov/business/programs/elliptic_curve.shtml which recommends rsa 3k for use with aes128/sha256, rsa 7k for aes192/sha384 and rsa 15k for aes256/sha512. If 3k provides comparable security to aes128 and sha256, and one needs to more than double the rsa key length to compare with aes192 and sha384, there is no reason to bother with rsa 4k. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Re: linux-firmware
On Wed, Feb 20, 2013 at 07:25:14PM +0100, Peter Stuge wrote: Greg KH wrote: If there really are firmware blobs that are only available via git and which cannot be redistributed we might consider whether it makes sense to not support them entirely, or to force them to be masked. Did anyone actually consider the fact that there should not be non-redistributable firmware blobs in the upstream git tree in the first place, as it is the thing that is doing the redistributing originally? I think non-redistributable in this case means by Gentoo since that was identified to be the case for some of the files in the git repository. Their license allows them to be distributed in linux-firmware.git, but not elsewhere. Really? What firmware files are that way, I just did a quick scan through the upstream linux-firmware.git tree and didn't see anything that would prevent Gentoo from doing this. What did I miss? thanks, greg k-h
Re: [gentoo-dev] Re: linux-firmware
On 20/02/2013 19:43, Greg KH wrote: Really? What firmware files are that way, I just did a quick scan through the upstream linux-firmware.git tree and didn't see anything that would prevent Gentoo from doing this. No, not really. Greg, please don't expect everybody's word here to be the Project's as you did already once - especially not if they are not even really involved in it. Ulrich Mueller (ulm) wrote this on the 16th: Look into the WHENCE file and be horrified. Taking just the first ten items (of a total 114): Unknown license (3 times) GPL, but without source (3 times) All rights reserved BSD, without source Right for redistribution not granted Permission is hereby granted for the distribution [...] as part of a Linux or other Open Source operating system kernel With one exception, we are not even allowed to redistribute these. This is what we've been discussing about. This is not really about Gentoo by itself, but the ability to distribute the sources at all, be it from us or somebody else. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
[gentoo-dev] g-elisp repository helper
Hi all, I do not know whether this list is an appropriate place, so sorry if it is not ) Recently I've wrote some little scripts that implement interface for g-common type repositories of layman[1]. And I would ask those who is interested to test them. I've created two packages: g-common (interacts with layman) and g-elisp (generates ebuilds). g-elisp is aimed to automatically create layman overlays for repositories of elisp packages supported by package.el, so those packages could be installed by portage. To test it you can add an overlay described by this xml-file: https://github.com/jauhien/jauhien-overlay/blob/master/jauhien-overlay.xml and then `emerge g-elisp` After emerging it you will be able to add two layman repositories of type g-common: gnu-elpa and marmalade. g-common and g-elisp are still in the very beta, also I'm a very beginner in python, so I will appreciate any feedback and criticism. Jauhien [1] http://git.overlays.gentoo.org/gitweb/?p=proj/layman.git;a=blob;f=layman/overlays/g_common.py;h=5f0e9bc341028248ccd718eff84d304100180949;hb=HEAD https://github.com/jauhien/g-common https://github.com/jauhien/g-elisp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: linux-firmware
Diego Elio Pettenò schrieb: linux-firmware[non-free] - the use flag to toggle between free and non-free licenses. linux-firmware-noredist - This one is RESTRICT=fetch mirror +1 — It requires some work from someone to actually split the stuff manually though, and there is at least one problem: somebody _got_ to redist the firmware for it to be fetched.. unless. Distinguishing between free and non-free firmware would be ok with me but I am not going to invest any work in that. I think the bindist flag is suitable for toggling the download of non-redistributable firmware. Possibly SRC_URI for the non-redistributable files can point to upstream gitweb. Although I don't know happy upstream will be when hordes of Gentoo users start hammering their servers. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: linux-firmware
Rich Freeman schrieb: Probably makes sense to have a few tiers: 1. Free 2. Non-free, but redistributable 3. Non-free, nonredistributable, but fetchable (maybe combine with #2) 4. Non-fetchable - do not combine. I don't see a reason for fetch restriction, as long as a direct download link from upstream exists (via gitweb). Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: linux-firmware
On Wed, Feb 20, 2013 at 2:20 PM, Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Rich Freeman schrieb: 4. Non-fetchable - do not combine. I don't see a reason for fetch restriction, as long as a direct download link from upstream exists (via gitweb). Agreed. You would only fetch-restrict a file if it wasn't fetchable or redistributable. If that is the empty set, then great. If not, then split them up and fetch-restrict them. Rich
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Wed, Feb 20, 2013 at 01:41:03PM -0500, James Cloos wrote: RHJ == Robin H Johnson robb...@gentoo.org writes: RHJ 2. Root key type of RSA, 4096 bits rsa 4k provides no real benefits over rsa 3k here; it is just slower for everyone, signing or verifying. You can shorten the subkeys, but the root key should ONLY be used for certifications key operations, not signing of external objects. The subkeys should be used for the external objects, and that's where you'd shorten if you really wanted. However, I'd suggest you not bother. Cf, eg, http://www.nsa.gov/business/programs/elliptic_curve.shtml which recommends rsa 3k for use with aes128/sha256, rsa 7k for aes192/sha384 and rsa 15k for aes256/sha512. If 3k provides comparable security to aes128 and sha256, and one needs to more than double the rsa key length to compare with aes192 and sha384, there is no reason to bother with rsa 4k. Speed for i7-2600K CPU: DSA1024 0.007980s DSA2048 0.011940s DSA3072 0.013530s RSA1024 0.007000s RSA2048 0.012290s RSA3072 0.018420s RSA4096 0.030800s 30ms is still an acceptable signing time - not noticeably different than RSA2048/RSA3072. Better question to all of this, is there somebody with a PGP smartcard that can do the same tests? I'll provide some scripts for the testcase itself, but you'll have to see about generating a bunch of keys on the smartcard, which might be problematic. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Re: linux-firmware
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/20/2013 12:32 PM, Diego Elio Pettenò wrote: On 20/02/2013 18:28, Rich Freeman wrote: Agreed, especially if only 1-2 files are involved. If it is a bunch that could get unwieldy. Wasn't really thinking about that option. That being the case, splitting them in multiple packages might indeed be a better option. Yes I know I'm the one pushing for using a single package — as long as it doesn't have licensing issues of course. I'm fine splitting the package into linux-firmware[non-free] and linux-firmware-restricted (or something like that). When I say I want one one ebuild for all firmware I really don't care to include fetch-restricted and the like in that. I'm very happy to have one ebuild for free and redistributable firmware and then have multiple other ebuilds as appropriate for the non-redistributable stuff. Thanks, Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRJSa2AAoJEKXdFCfdEflKSM0P/jjNsGH7MW8rcCRkMsL/i4mw 08CBJ/mxl81YnKPZGoXS0JcMG9LmCjW+2f87JBmMAk8cOPJhzlGV7V8y7GlY+BgF oz37nfOqJVciY2sWqPze+H1bH0crrrBZhIDTnCfo/ryRPR+oTTQdO4xRxIXOe3Fo Fw6VJPQkCLFFMwraOYBxcrXPmGQ7RVz8MvmyeVcJH5lUFh7wi/dPu/Iwqu2dX4Yc faXOCBzU06r62CvWt1+7msouO6Y+f4Hh1XcOe2cXCLsZJj+74WiQzXeQB7iQv0F+ zE/p6Stee5yhrn9bhB/mASeBk9YvyztUng8IIigNdnFovAhUyZp86wvEt7xd0rqp N8U7WHnSYzfU8Wntr/p1ZHHYsvmdwJToRsh6e9+IrX0i82W+I6b6s9L0n1+SqIIY fCacto2idRN4k9lQ51beEq7ZqqCcLpPuWthTzVT9E3obCH8UrFlFFvImMtdJyMq1 4J8MWRVSWUPwEn84Yu5RpPxl3aOmqfv5cVzUqXmYy1hYQb0P4e/43+L0hyQvthPR N6htokFjS0iWpYklp6hkSt+VdBUf6wF/4ytNjeAd0BhpRWK/diDiysKDTHVAPswB 0PX6cX++uYPVNTD+PdaW2PbFVwzKgCzUI185dw26rBjarRJpfhdcrPyIMXGeEqa6 RoR0efRHAnraGw/qqL8v =lAF5 -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: Gentoo GPG key policies
Am Mittwoch, 20. Februar 2013, 20:36:22 schrieb Robin H. Johnson: Speed for i7-2600K CPU: DSA1024 0.007980s DSA2048 0.011940s DSA3072 0.013530s RSA1024 0.007000s RSA2048 0.012290s RSA3072 0.018420s RSA4096 0.030800s Which of course brings up the question, why the hardcoded 4096 limit in GnuPG... but I guess that's not our problem yet. https://www.google.de/search?q=gnupg+rsa+8192 -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Mon, 18 Feb 2013 23:27:46 + Robin H. Johnson robb...@gentoo.org wrote: 3. Dedicated Gentoo signing subkey What's the point of this, btw? Luis signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Wed, Feb 20, 2013 at 09:22:05PM +0100, Andreas K. Huettel wrote: Which of course brings up the question, why the hardcoded 4096 limit in GnuPG... but I guess that's not our problem yet. https://www.google.de/search?q=gnupg+rsa+8192 Standards interoperability. RSA4096 will not work on legacy PGP implementations key servers. The next release of the OpenPGP spec is supposed to raise this. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Wed, Feb 20, 2013 at 09:38:38PM +0100, Luis Ressel wrote: On Mon, 18 Feb 2013 23:27:46 + Robin H. Johnson robb...@gentoo.org wrote: 3. Dedicated Gentoo signing subkey What's the point of this, btw? Ideally keeping your primary key offline to increase security. However, the original theory was that if there was some attack that required a large amount of ciphertext or a targeted plaintext input, you would be limiting the ciphertext to only gentoo-specific content, and could trivially rotate the subkey without any impact on your primary key. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Wed, 20 Feb 2013 21:37:38 + Robin H. Johnson robb...@gentoo.org wrote: Ideally keeping your primary key offline to increase security. However, the original theory was that if there was some attack that required a large amount of ciphertext or a targeted plaintext input, you would be limiting the ciphertext to only gentoo-specific content, and could trivially rotate the subkey without any impact on your primary key. I totally agree with the idea of having a separate subkey for signing purposes, but look at my key, for example: I already have a separate subkey for signing, the primary key is only used for certifications (and is actually kept offline ;). If I was a Gentoo dev, it wouldn't seem that logical to have to create yet another signing subkey. Therefore, I'd propose to remove the Gentoo part from Dedicated Gentoo signing subkey. Luis signature.asc Description: PGP signature
Re: [gentoo-portage-dev] emerge @preserved-rebuild not rebuilding all broken packages after udev update
El mar, 19-02-2013 a las 14:27 -0800, Zac Medico escribió: On 02/19/2013 12:12 PM, Pacho Ramos wrote: Hello For some time I am running portage-2.1.x with preserve-libs enabled to test it and try to prevent revdep-rebuild usage. Until now, I haven't had any problems with it, but I started to test it after being running udev-19x for a long time. Yesterday, my father mailed me because he got udev update from 17x to 19x and emerge @preserved-rebuild only rebuilt gcc, keeping other broken packages untouched (while revdep-rebuild rebuilt them) Do you know what kind of information could I demand him to help diagnose the problem? It only works if the broken packages have references to the libudev.so.0 (or maybe libgudev-1.0.so.0) soname in their /var/db/pkg/*/*/NEEDED.ELF.2 files. Will need to recheck in next breakage then :/ Any suggestion about how to proceed when I hit this kind of problem? (I mean, what can I provide you to try to fix this cases) Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] emerge @preserved-rebuild not rebuilding all broken packages after udev update
On 02/20/2013 12:53 PM, Pacho Ramos wrote: El mar, 19-02-2013 a las 14:27 -0800, Zac Medico escribió: On 02/19/2013 12:12 PM, Pacho Ramos wrote: Hello For some time I am running portage-2.1.x with preserve-libs enabled to test it and try to prevent revdep-rebuild usage. Until now, I haven't had any problems with it, but I started to test it after being running udev-19x for a long time. Yesterday, my father mailed me because he got udev update from 17x to 19x and emerge @preserved-rebuild only rebuilt gcc, keeping other broken packages untouched (while revdep-rebuild rebuilt them) Do you know what kind of information could I demand him to help diagnose the problem? It only works if the broken packages have references to the libudev.so.0 (or maybe libgudev-1.0.so.0) soname in their /var/db/pkg/*/*/NEEDED.ELF.2 files. Will need to recheck in next breakage then :/ Any suggestion about how to proceed when I hit this kind of problem? (I mean, what can I provide you to try to fix this cases) Create a tarball of /var/db/pkg when it's in a misbehaving state, so we can us it for analysis later, after the state has changed. -- Thanks, Zac
