Re: [gentoo-dev] Portage feature addition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Drake wrote: > Alec Warner wrote: >> This is to prevent people from sticking a random unchecksum'd ebuild >> in your tree and then having portage source it for depend() metadata >> and then getting bitten by some global scope nasties. > > Is this really the correct solution to this "problem"? > > I can't see the use case: do people really download (potentially > malicious) ebuilds, stick them in their overlay, and then *not* use them? > > Somehow I don't think that's true - people will generally download > ebuilds, and use them (even if they fail during compilation, they will > have been used in some form). > > If you start requiring people to create Manifests for these ebuilds, > they will do so, and this has not changed the security implications of > these "untrusted" ebuilds. > > Am I missing something? > > Daniel The plan is to eventually include digital signature verification together with the Manifest verification. The framework isn't completely implemented yet, but we're beginning to put some of the required mechanisms into place. Considering that repoman users generally have complete trust in their cvs checkout, I suppose it would make sense to allow repoman features to be configured separately. For example, we could allow you to set REPOMAN_FEATURES="-strict" in make.conf so that you won't be bothered by broken Manifests when running repoman. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFc4bT/ejvha5XGaMRAiYbAJwIWJF7lCR7ICMmJGAfDOQlZNtlHACfYqJp fUERS53nyQ2kQf1QMb3rd5k= =5cht -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Portage feature addition
Alec Warner wrote: This is to prevent people from sticking a random unchecksum'd ebuild in your tree and then having portage source it for depend() metadata and then getting bitten by some global scope nasties. Is this really the correct solution to this "problem"? I can't see the use case: do people really download (potentially malicious) ebuilds, stick them in their overlay, and then *not* use them? Somehow I don't think that's true - people will generally download ebuilds, and use them (even if they fail during compilation, they will have been used in some form). If you start requiring people to create Manifests for these ebuilds, they will do so, and this has not changed the security implications of these "untrusted" ebuilds. Am I missing something? Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Portage feature addition
Jeroen Roovers wrote: On Sun, 03 Dec 2006 15:03:27 -0800 Zac Medico <[EMAIL PROTECTED]> wrote: Apparently `repoman fix` doesn't currently work for that particular case, which is definitely a bug. If you can simply run `repoman fix`, will that be convenient enough? I would like to be able to run `repoman full` without needing to touch the digests at all or with FEATURES=-strict. For an arch dev, the digests are normally fine already and Manifest is automatically fixed when running repoman commit. The danger of global scope nasties ought to be very limited by the time a package is ready for arch keywording. FEATURES="digest" repoman full -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Portage feature addition
On Sun, 03 Dec 2006 15:03:27 -0800 Zac Medico <[EMAIL PROTECTED]> wrote: > Apparently `repoman fix` doesn't currently work for that particular > case, which is definitely a bug. If you can simply run `repoman > fix`, will that be convenient enough? I would like to be able to run `repoman full` without needing to touch the digests at all or with FEATURES=-strict. For an arch dev, the digests are normally fine already and Manifest is automatically fixed when running repoman commit. The danger of global scope nasties ought to be very limited by the time a package is ready for arch keywording. The problem with FEATURES=-strict is that it isn't clear what it is actually being strict (or loose) about (maybe the make.conf man page needs to be updated). Obviously, repoman is *already* able to tell me whether a digest or Manifest is bad, and should be able to report this along with all the things it checks for by sourcing the ebuild(s). IMO this new feature should be enabled only with FEATURES=stricter or some other smartly named FEATURES flag. Kind regards, JeR -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Portage feature addition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeroen Roovers wrote: > On Sun, 03 Dec 2006 01:00:24 -0500 > Alec Warner <[EMAIL PROTECTED]> wrote: > >> This 'feature' is currently controlled via strict, so those that hate >> hate hate it can turn it off via FEATURES="-strict" > > It seems that now I have to run repoman with FEATURES=-strict after I > do as little as change a keyword without running `ebuild > manifest`. Is this intended behaviour or a bug? It's highly > inconvenient... Whether it's a feature or a bug depends on how you look a it. Apparently `repoman fix` doesn't currently work for that particular case, which is definitely a bug. If you can simply run `repoman fix`, will that be convenient enough? Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFc1e9/ejvha5XGaMRAqS6AKDJ92GO6wUgMqttIwHLt7daYhWp6QCfT/pd BUou3dPOeEwaC7UX8q/twJA= =FtkT -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Portage feature addition
On Sun, 03 Dec 2006 01:00:24 -0500 Alec Warner <[EMAIL PROTECTED]> wrote: > This 'feature' is currently controlled via strict, so those that hate > hate hate it can turn it off via FEATURES="-strict" It seems that now I have to run repoman with FEATURES=-strict after I do as little as change a keyword without running `ebuild manifest`. Is this intended behaviour or a bug? It's highly inconvenient... Kind regards, JeR -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Portage feature addition
Mike Frysinger wrote: On Sunday 03 December 2006 01:00, Alec Warner wrote: Recently commited to svn (but afaik released only in ~arch) is code to prevent the sourcing of ebuilds with no manifest. Thus ebuilds you randomly download off of bugzilla need to get a lookover from you and then ebuild foo.ebuild digest'd. i thought portage always did that ... if you have FEATURES=strict, it'll complain that a file doesnt exist in the Manifest and abort -mike It will if you try to *install* the ebuild. But we source it for depend info long before that happens. If we have the depend info cached, we trust the cache info to calculate dependencies for other packages, even if the ebuild has an incorrect checksum (afaik). -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Portage feature addition
On Sun, 2006-12-03 at 14:33 -0500, Mike Frysinger wrote: > On Sunday 03 December 2006 01:00, Alec Warner wrote: > > Recently commited to svn (but afaik released only in ~arch) is code to > > prevent the sourcing of ebuilds with no manifest. Thus ebuilds you > > randomly download off of bugzilla need to get a lookover from you and > > then ebuild foo.ebuild digest'd. > > i thought portage always did that ... if you have FEATURES=strict, it'll > complain that a file doesnt exist in the Manifest and abort Nope.. Try this.. cd $(portageq envvar PORTDIR)/virtual/ mkdir mike cd mike echo 'echo OWNED at phase $EBUILD_PHASE' > mike-0.0.ebuild emerge -pv mike > -mike -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Portage feature addition
On Sunday 03 December 2006 01:00, Alec Warner wrote: > Recently commited to svn (but afaik released only in ~arch) is code to > prevent the sourcing of ebuilds with no manifest. Thus ebuilds you > randomly download off of bugzilla need to get a lookover from you and > then ebuild foo.ebuild digest'd. i thought portage always did that ... if you have FEATURES=strict, it'll complain that a file doesnt exist in the Manifest and abort -mike pgpD0SmI16Q3w.pgp Description: PGP signature
Re: [gentoo-dev] Portage feature addition
Mike Doty wrote: Alec Warner wrote: Just make you aware, not everyone follows portage development and its bound to bite some people in the ass (although I expect the users will notice the most). Recently commited to svn (but afaik released only in ~arch) is code to prevent the sourcing of ebuilds with no manifest. Thus ebuilds you randomly download off of bugzilla need to get a lookover from you and then ebuild foo.ebuild digest'd. This is to prevent people from sticking a random unchecksum'd ebuild in your tree and then having portage source it for depend() metadata and then getting bitten by some global scope nasties. This 'feature' is currently controlled via strict, so those that hate hate hate it can turn it off via FEATURES="-strict" It's implemented in doebuild, so any ops that aren't 'digest/manifest/help' aren't allowed on manifest-less ebuilds. This includes the 'ebuild' utility. Having FEATURES="digest" should also disable this check. I figured people would start asking about the failures, so better to explain now ;) The error is obvious and contains the solution or will we have a influx of bugs? That depends on how smart people are :p The error is basically "manifest missing for /path/to/missing/manifest" and then it dies. You could probably convince Zac to add the solution or a link to a URL that explains what to do. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Portage feature addition
Alec Warner wrote: Just make you aware, not everyone follows portage development and its bound to bite some people in the ass (although I expect the users will notice the most). Recently commited to svn (but afaik released only in ~arch) is code to prevent the sourcing of ebuilds with no manifest. Thus ebuilds you randomly download off of bugzilla need to get a lookover from you and then ebuild foo.ebuild digest'd. This is to prevent people from sticking a random unchecksum'd ebuild in your tree and then having portage source it for depend() metadata and then getting bitten by some global scope nasties. This 'feature' is currently controlled via strict, so those that hate hate hate it can turn it off via FEATURES="-strict" It's implemented in doebuild, so any ops that aren't 'digest/manifest/help' aren't allowed on manifest-less ebuilds. This includes the 'ebuild' utility. Having FEATURES="digest" should also disable this check. I figured people would start asking about the failures, so better to explain now ;) The error is obvious and contains the solution or will we have a influx of bugs? -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Portage feature addition
Just make you aware, not everyone follows portage development and its bound to bite some people in the ass (although I expect the users will notice the most). Recently commited to svn (but afaik released only in ~arch) is code to prevent the sourcing of ebuilds with no manifest. Thus ebuilds you randomly download off of bugzilla need to get a lookover from you and then ebuild foo.ebuild digest'd. This is to prevent people from sticking a random unchecksum'd ebuild in your tree and then having portage source it for depend() metadata and then getting bitten by some global scope nasties. This 'feature' is currently controlled via strict, so those that hate hate hate it can turn it off via FEATURES="-strict" It's implemented in doebuild, so any ops that aren't 'digest/manifest/help' aren't allowed on manifest-less ebuilds. This includes the 'ebuild' utility. Having FEATURES="digest" should also disable this check. I figured people would start asking about the failures, so better to explain now ;) -- gentoo-dev@gentoo.org mailing list
