Re: vsftpd in the news
On Tue, 05 Jul 2011 17:05:45 -0500, MC (Michael) wrote: Some packagers do upload the detached sig and add it to the spec as another Source file URL. Great! Except I haven't done so. I wasn't required to submit a signature for my package nor does the Package Guildline pages refer to doing so. Might be worth someone's time to mention it on the wiki (who knows about this functionality). It isn't any functionality. It is just possible to place a tarball and its detached GPG sig file in the source RPM package for anyone who may want to verify the sig manually at some point in time. Verifying detached tarball sigs isn't trivial or 100% safe anyway. One needs to be very familiar with the signer's key(s). Else the risk is too high that a user simply fetches a needed key from a key server without applying extra care. And for a sufficiently large tarball of a project with N1 devs, has the signer been able to actually verify all source code changes prior to signing the tarball? Or is the signature only used to flag a package as coming from a trusted project developer without any additional guarantees? A tarball sig is just one layer of safety, but no ultimate protection. The uploaded tarball checksum enters the sources file in git, and any tarball downloaded from the lookaside cache MUST match that checksum. Else it wouldn't be downloaded and used. Source RPM build in koji would fail. This is just a checksum against the tarball that enters the lookaside cache. Yes, I know about this. A malicious package could have been uploaded to the lookaside cache, however. This leads to demanding everyone have signatures available, but what do you do about SVN/Git checkouts or projects that don't wish to provide signatures? Obviously, one needs to be very careful, skim over diffs, monitor commits regularly, archive snapshots regularly, be familiar with upstream release habits. Upstream also needs to do that, to avoid that a compromised account from a committer is used to infiltrate the project. If a source code repository is modified without permission and no developer (or release manager) notices it, would the person adding the tarball sig notice it? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On Tue, 05 Jul 2011 21:02:33 -0700, AW (Adam) wrote: There's a few cavets that have been mentioned in this thread that would make this functionality mostly pointless to try and implement. 1) Not all packages include gpg signatures. a) not everyone knows they can include them b) SCM checkouts don't have signatures c) some projects don't use them 2) We don't have a system to validate a gpg signature in place. My understanding of GPG is that we would need to house all the public keys to validate against. Nothing like this exists. I'm lazy and don't feel like creating such a system. :) We're stuck with the lookaside cache checksum for now. 1) doesn't really matter. So we get some assurance for some packages, not all; it's still better than none. Don't make the perfect the enemy of the good. 2) ditto - we can 'house' them in so far as including them as package sources. If they aren't included then don't run the check. If they are, run the check... If we include the whole show in the src.rpm, how does that add any safety? Doesn't that make it easier to compromise the src.rpm by replacing tarball, sig, and key? How does the check know whether an included key is the right one and can be trusted, too? Even included tarball sigs would need another layer, such as the package creator signing off all files (large or compressed patches, too!) with either a personal key or with a project signing-server. Just another layer, though... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On Wed, Jul 6, 2011 at 9:19 AM, Michael Schwendt mschwe...@gmail.com wrote: On Tue, 05 Jul 2011 21:02:33 -0700, AW (Adam) wrote: 2) We don't have a system to validate a gpg signature in place. My understanding of GPG is that we would need to house all the public keys to validate against. Nothing like this exists. I'm lazy and don't feel like creating such a system. :) 2) ditto - we can 'house' them in so far as including them as package sources. If they aren't included then don't run the check. If they are, run the check... If we include the whole show in the src.rpm, how does that add any safety? It can protect Fedora against substituted upstream tarballs (i.e. if the new upstream version has an incorrect signature, we would notice). Doesn't that make it easier to compromise the src.rpm by replacing tarball, sig, and key? That's protecting Fedora users against substituted Fedora RPMs, which is quite orthogonal to protecting Fedora against upstream tarballs. How does the check know whether an included key is the right one and can be trusted, too? The package maintainer can decide who is trusted to publish upstream releases, and list the trusted keys in a config file. Even included tarball sigs would need another layer, such as the package creator signing off all files (large or compressed patches, too!) with either a personal key or with a project signing-server. Just another layer, though... Yes, we could require gpg-signed git commits; but note that this wouldn't be a protection against hijacked Fedora accounts, IMHO the most likely avenue of attack. gpg-signed git commits would protect the integrity/verifiability of the git history (e.g. against attacks directly on the git repo storage, or against an attacker having root on the Fedora servers) - but only as long as the Fedora account system (housing the public keys of package maintainers) would not be compromised as wel. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
06.07.2011, 16:07, Michael Schwendt mschwe...@gmail.com: And for a sufficiently large tarball of a project with N1 devs, has the signer been able to actually verify all source code changes prior to signing the tarball? Or is the signature only used to flag a package as coming from a trusted project developer without any additional guarantees? A tarball sig is just one layer of safety, but no ultimate protection. The uploaded tarball checksum enters the sources file in git, and any tarball downloaded from the lookaside cache MUST match that checksum. Else it wouldn't be downloaded and used. Source RPM build in koji would fail. This is just a checksum against the tarball that enters the lookaside cache. Yes, I know about this. A malicious package could have been uploaded to the lookaside cache, however. This leads to demanding everyone have signatures available, but what do you do about SVN/Git checkouts or projects that don't wish to provide signatures? Obviously, one needs to be very careful, skim over diffs, monitor commits regularly, archive snapshots regularly, be familiar with upstream release habits. Upstream also needs to do that, to avoid that a compromised account from a committer is used to infiltrate the project. If a source code repository is modified without permission and no developer (or release manager) notices it, would the person adding the tarball sig notice it? The developer of vsftpd didn't notice the change, but still there was early prevention possible. The issue is *one* of the ways source code can be exploited, and checking the gpg signatures for the projects that allow it is a measure against the particular kind of attack. Literally, it would close one vulnerability in the distro. Which is enough. -- Best regards, Misha Shnurapet, Fedora Project Contributor Email: shnurapet AT fedoraproject.org, IRC: misha on freenode https://fedoraproject.org/wiki/shnurapet, GPG: 00217306 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On Wed, 6 Jul 2011 09:48:24 +0200, MT (Miloslav) wrote: On Tue, 05 Jul 2011 21:02:33 -0700, AW (Adam) wrote: 2) We don't have a system to validate a gpg signature in place. My understanding of GPG is that we would need to house all the public keys to validate against. Nothing like this exists. I'm lazy and don't feel like creating such a system. :) 2) ditto - we can 'house' them in so far as including them as package sources. If they aren't included then don't run the check. If they are, run the check... If we include the whole show in the src.rpm, how does that add any safety? It can protect Fedora against substituted upstream tarballs (i.e. if the new upstream version has an incorrect signature, we would notice). The packager should have noticed already. If the sig file is added to the src.rpm and the public key has been added to it [a long time] before, all AutoQA would add is to detect the case when the packager added a new tarball+sig without verifying it beforehand. Right? Doesn't that make it easier to compromise the src.rpm by replacing tarball, sig, and key? That's protecting Fedora users against substituted Fedora RPMs, which is quite orthogonal to protecting Fedora against upstream tarballs. If it's possible to hack a web page and replace a tarball, it would also be possible to replace a detached sig file (or even add a faked one for the first time and pretend that it's a new feature of the release process). It wouldn't be the first project where the signer and/or the signing key has changed, and where the downloader needs to decide on whether to trust the key that has been used. That is, not just use --recv-keys to fetch it from a key server. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On Wed, Jul 6, 2011 at 10:43 AM, Michael Schwendt mschwe...@gmail.com wrote: On Wed, 6 Jul 2011 09:48:24 +0200, MT (Miloslav) wrote: If we include the whole show in the src.rpm, how does that add any safety? It can protect Fedora against substituted upstream tarballs (i.e. if the new upstream version has an incorrect signature, we would notice). The packager should have noticed already. If the sig file is added to the src.rpm and the public key has been added to it [a long time] before, all AutoQA would add is to detect the case when the packager added a new tarball+sig without verifying it beforehand. Right? Exactly. If it's possible to hack a web page and replace a tarball, it would also be possible to replace a detached sig file (or even add a faked one for the first time and pretend that it's a new feature of the release process). It wouldn't be the first project where the signer and/or the signing key has changed, and where the downloader needs to decide on whether to trust the key that has been used. That is, not just use --recv-keys to fetch it from a key server. That's an interesting subproblem, especially if the signing key were lost. In practice, handling a key change can probably be done reasonably securely even in such cases, e.g. by announcing the key change on the project's mailing list where the holder of the previous key and the project's governing body would have to notice the announcement, and waiting long enough to allow for the project members to contradict the announcement. From the Fedora point of view, we don't need to do anything special - the package maintainer would or would not update the list of trusted tarball signers depending on the packager's view of the situation. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On 07/06/2011 03:19 AM, Michael Schwendt wrote: If we include the whole show in the src.rpm, how does that add any safety? It doesn't make the system bulletproof, but it makes it a little harder to break, and, perhaps more importantly, adds accountability, i.e. helps to figure out at which point the source was corrupted. Remember the original Linux kernel trojan: it was discovered because the bitkeeper checksums showed an unaccounted-for chunk. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On Mon, 4 Jul 2011 23:53:38 -0400 (EDT), PW (Paul) wrote: It would be nice if we could upload/commit the .asc or .sig file, and have the rpmbuild script automatically check the tar ball. Some packagers do upload the detached sig and add it to the spec as another Source file URL. The uploaded tarball checksum enters the sources file in git, and any tarball downloaded from the lookaside cache MUST match that checksum. Else it wouldn't be downloaded and used. Source RPM build in koji would fail. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
Michael Schwendt mschwe...@gmail.com writes: The uploaded tarball checksum enters the sources file in git, and any tarball downloaded from the lookaside cache MUST match that checksum. Else it wouldn't be downloaded and used. Source RPM build in koji would fail. That won't help if the tarball is already defective when uploaded. The checksum is basically only used to identify the blob in the cache, at most to detect cache corruptions. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On Mon, 2011-07-04 at 23:27 -0500, Michael Cronenworth wrote: On 07/04/2011 10:53 PM, Paul Wouters wrote: It would be nice if we could upload/commit the .asc or .sig file, and have the rpmbuild script automatically check the tar ball. Hm, yes. It would be nice to see Koji support checking source sigs. OBS already does so. Seeing as Debian has done this for years with the source .deb including a signature file, RPM 4.9 could support sigs for the Source0 file. Making Source0 a special case sounds rather dirty to me, if at all such functionality should be available for all source files (and patches eventually). Furthermore, just having a signature file doesn't help a bit if you can't be sure who created the signature... and I suspect if we were to restrict ourselves to upstream packages that a) have gpg signatures b) from keypairs not more than a certain distance (web-of-trust-wise) away from a known good keypair, we'd be able to trim down the package repositories substantially ;-). So for the time being I guess we should stick with letting package maintainers check this (of there is anything to check). Nils -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On Tue, 05 Jul 2011 11:01:15 +0200, AS (Andreas) wrote: The uploaded tarball checksum enters the sources file in git, and any tarball downloaded from the lookaside cache MUST match that checksum. Else it wouldn't be downloaded and used. Source RPM build in koji would fail. That won't help if the tarball is already defective when uploaded. The checksum is basically only used to identify the blob in the cache, at most to detect cache corruptions. And I didn't claim otherwise. The post I replied to already had mentioned: | For Fedora, package maintainers are responsible for uploading verified | tar balls to the fedora build system. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On Mon, 2011-07-04 at 23:27 -0500, Michael Cronenworth wrote: In the mean time, perhaps AutoQA could have a check added against the source checksum? That sounds like an excellent idea for a contribution! Remember, the AutoQA project is explicitly designed to allow and indeed encourage tests to be contributed - we would love it if the core AutoQA team worked mostly on the framework, and tests were contributed by many people. See https://fedoraproject.org/wiki/Writing_AutoQA_Tests . -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On Tue, 2011-07-05 at 11:13 +0200, Nils Philippsen wrote: On Mon, 2011-07-04 at 23:27 -0500, Michael Cronenworth wrote: On 07/04/2011 10:53 PM, Paul Wouters wrote: It would be nice if we could upload/commit the .asc or .sig file, and have the rpmbuild script automatically check the tar ball. Hm, yes. It would be nice to see Koji support checking source sigs. OBS already does so. Seeing as Debian has done this for years with the source .deb including a signature file, RPM 4.9 could support sigs for the Source0 file. Making Source0 a special case sounds rather dirty to me, if at all such functionality should be available for all source files (and patches eventually). Furthermore, just having a signature file doesn't help a bit if you can't be sure who created the signature... and I suspect if we were to restrict ourselves to upstream packages that a) have gpg signatures b) from keypairs not more than a certain distance (web-of-trust-wise) away from a known good keypair, we'd be able to trim down the package repositories substantially ;-). So for the time being I guess we should stick with letting package maintainers check this (of there is anything to check). I didn't see any suggestion that packages be *required* to have a signature, only that we somehow run an automated check on one if there is one. Rather than making specific Source numbers special case, why not just go on naming? The convention for signatures is to add an extension to the name of the tarball the signature is for; that shouldn't be too hard to implement, I don't think. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On 07/05/2011 05:15 PM, Adam Williamson wrote: I didn't see any suggestion that packages be *required* to have a signature, only that we somehow run an automated check on one if there is one. Rather than making specific Source numbers special case, why not just go on naming? The convention for signatures is to add an extension to the name of the tarball the signature is for; that shouldn't be too hard to implement, I don't think. Surely the automated testing tool would need a way of being fed known-trusted public keys in advance as well? -- Benjamin Lewis Returning Officer and Past-President Durham Union Society Mobile: +44 7540 379074 Office: +44 191 384 3724 Pemberton Buildings, Palace Green, Durham signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On Tue, Jul 5, 2011 at 7:43 PM, Benjamin Lewis ben.le...@benl.co.uk wrote: On 07/05/2011 05:15 PM, Adam Williamson wrote: I didn't see any suggestion that packages be *required* to have a signature, only that we somehow run an automated check on one if there is one. Rather than making specific Source numbers special case, why not just go on naming? The convention for signatures is to add an extension to the name of the tarball the signature is for; that shouldn't be too hard to implement, I don't think. Surely the automated testing tool would need a way of being fed known-trusted public keys in advance as well? Unless my memory is failing me, we already had a mechanism for this (specifying the trusted keys and verifying signatures) in the CVS package repository (in Makefile.common). Perhaps most of that could be reused. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On 07/05/2011 03:46 AM, Michael Schwendt wrote: Some packagers do upload the detached sig and add it to the spec as another Source file URL. Great! Except I haven't done so. I wasn't required to submit a signature for my package nor does the Package Guildline pages refer to doing so. Might be worth someone's time to mention it on the wiki (who knows about this functionality). The uploaded tarball checksum enters the sources file in git, and any tarball downloaded from the lookaside cache MUST match that checksum. Else it wouldn't be downloaded and used. Source RPM build in koji would fail. This is just a checksum against the tarball that enters the lookaside cache. Yes, I know about this. A malicious package could have been uploaded to the lookaside cache, however. This leads to demanding everyone have signatures available, but what do you do about SVN/Git checkouts or projects that don't wish to provide signatures? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On 07/05/2011 11:59 AM, Adam Williamson wrote: That sounds like an excellent idea for a contribution! Remember, the AutoQA project is explicitly designed to allow and indeed encourage tests to be contributed - we would love it if the core AutoQA team worked mostly on the framework, and tests were contributed by many people. Seehttps://fedoraproject.org/wiki/Writing_AutoQA_Tests . There's a few cavets that have been mentioned in this thread that would make this functionality mostly pointless to try and implement. 1) Not all packages include gpg signatures. a) not everyone knows they can include them b) SCM checkouts don't have signatures c) some projects don't use them 2) We don't have a system to validate a gpg signature in place. My understanding of GPG is that we would need to house all the public keys to validate against. Nothing like this exists. I'm lazy and don't feel like creating such a system. :) We're stuck with the lookaside cache checksum for now. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On Tue, 2011-07-05 at 17:11 -0500, Michael Cronenworth wrote: On 07/05/2011 11:59 AM, Adam Williamson wrote: That sounds like an excellent idea for a contribution! Remember, the AutoQA project is explicitly designed to allow and indeed encourage tests to be contributed - we would love it if the core AutoQA team worked mostly on the framework, and tests were contributed by many people. Seehttps://fedoraproject.org/wiki/Writing_AutoQA_Tests . There's a few cavets that have been mentioned in this thread that would make this functionality mostly pointless to try and implement. 1) Not all packages include gpg signatures. a) not everyone knows they can include them b) SCM checkouts don't have signatures c) some projects don't use them 2) We don't have a system to validate a gpg signature in place. My understanding of GPG is that we would need to house all the public keys to validate against. Nothing like this exists. I'm lazy and don't feel like creating such a system. :) We're stuck with the lookaside cache checksum for now. 1) doesn't really matter. So we get some assurance for some packages, not all; it's still better than none. Don't make the perfect the enemy of the good. 2) ditto - we can 'house' them in so far as including them as package sources. If they aren't included then don't run the check. If they are, run the check... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On Tue, 5 Jul 2011, Misha Shnurapet wrote: The backdoor payload is interesting. In response to a :) smiley face in the FTP username, a TCP callback shell is attempted. There is no obfuscation. I have a question: how does that relate to our package building process, and are GPG signatures verified? For Fedora, package maintainers are responsible for uploading verified tar balls to the fedora build system. I know I check the gpg signatures on the ones I upload, though these are not always available as separate sig files. It would be nice if we could upload/commit the .asc or .sig file, and have the rpmbuild script automatically check the tar ball. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On 07/04/2011 10:53 PM, Paul Wouters wrote: It would be nice if we could upload/commit the .asc or .sig file, and have the rpmbuild script automatically check the tar ball. Hm, yes. It would be nice to see Koji support checking source sigs. OBS already does so. Seeing as Debian has done this for years with the source .deb including a signature file, RPM 4.9 could support sigs for the Source0 file. In the mean time, perhaps AutoQA could have a check added against the source checksum? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
