Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Thursday 21 June 2007, Vlastimil Babka wrote: * dev-java/ibm-jdk-bin-1.5.0.5: package has RESTRICT=fetch/(no)mirror! * dev-java/ibm-jdk-bin-1.5.0.5: it may not be legal to redistribute this. this is incorrect ... while USE=bindist has an exact 1-to-1 correlation with the legality of building a binary package, the same cannot be said for RESTRICT=fetch/mirror Zach has added support for RESTRICT=bindist instead which ebuild writers may use -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 2007-06-20 at 23:04 -0400, Mike Frysinger wrote: On Wednesday 20 June 2007, Mike Frysinger wrote: On Wednesday 20 June 2007, Josh Saddler wrote: Do potential licensing/copyright issues like these factor into your proposal in any way? no, that's an exercise for the user and no one else ... there's no way i'd have the tools prevent this. about the only thing i'd add is a reminder message if binpkg is in IUSE and not in USE. i like this idea so it's been added: # quickpkg pycrypto * dev-python/pycrypto-2.0.1-r5: package was emerged with USE=-bindist! * dev-python/pycrypto-2.0.1-r5: it may not be legal to redistribute this. * Building package for dev-python/pycrypto-2.0.1-r5 ...[ ok ] * Packages now in '/usr/portage/packages': * dev-python/pycrypto-2.0.1-r5: 188K -mike Please do the same for qpkg.c tia. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger wrote: On Wednesday 20 June 2007, Mike Frysinger wrote: On Wednesday 20 June 2007, Josh Saddler wrote: Do potential licensing/copyright issues like these factor into your proposal in any way? no, that's an exercise for the user and no one else ... there's no way i'd have the tools prevent this. about the only thing i'd add is a reminder message if binpkg is in IUSE and not in USE. i like this idea so it's been added: # quickpkg pycrypto * dev-python/pycrypto-2.0.1-r5: package was emerged with USE=-bindist! * dev-python/pycrypto-2.0.1-r5: it may not be legal to redistribute this. * Building package for dev-python/pycrypto-2.0.1-r5 ...[ ok ] * Packages now in '/usr/portage/packages': * dev-python/pycrypto-2.0.1-r5: 188K -mike You should do also this (mockup): * dev-java/ibm-jdk-bin-1.5.0.5: package has RESTRICT=fetch/(no)mirror! * dev-java/ibm-jdk-bin-1.5.0.5: it may not be legal to redistribute this. * Building package for dev-java/ibm-jdk-bin-1.5.0.5 ... [ ok ] * Packages now in '/usr/portage-packages': * dev-java/ibm-jdk-bin-1.5.0.5: 50.9M - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGehf7tbrAj05h3oQRAi3BAJ9CIIQ4We8aY2LIRlCcXvhEO/04yACfRtrh Xn8cfOd3YLaHNp8H/efM84s= =FJ2n -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ned Ludd wrote: On Wed, 2007-06-20 at 23:04 -0400, Mike Frysinger wrote: On Wednesday 20 June 2007, Mike Frysinger wrote: On Wednesday 20 June 2007, Josh Saddler wrote: Do potential licensing/copyright issues like these factor into your proposal in any way? no, that's an exercise for the user and no one else ... there's no way i'd have the tools prevent this. about the only thing i'd add is a reminder message if binpkg is in IUSE and not in USE. i like this idea so it's been added: # quickpkg pycrypto * dev-python/pycrypto-2.0.1-r5: package was emerged with USE=-bindist! * dev-python/pycrypto-2.0.1-r5: it may not be legal to redistribute this. * Building package for dev-python/pycrypto-2.0.1-r5 ...[ ok ] * Packages now in '/usr/portage/packages': * dev-python/pycrypto-2.0.1-r5: 188K -mike Please do the same for qpkg.c tia. And for emerge -b/-B/FEATURES=buildpkg. Too bad people will miss those messages there anyway :) - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGehl8tbrAj05h3oQRAhWeAJ97LB2wCjQS9ClzfcVBZWWL4BU/mACfeUie 162BuT7lbvHmvxGaW7CCJbY= =+o1J -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
Hi! On Wed, 20 Jun 2007, Ciaran McCreesh wrote: On Wed, 20 Jun 2007 15:31:32 -0700 Chris Gianelloni [EMAIL PROTECTED] wrote: On Wed, 2007-06-20 at 22:01 +0100, Ciaran McCreesh wrote: The specific underlying question being, what are the use cases for binary packages? Ever managed a network of multiple Gentoo identical Gentoo machines? That's one use case, yes. Now what are the others? I sometimes help out with arch testing. I don't like having all the deps and packages installed even if I don't use them. So I usually quickpkg the and unmerge them. Advantage is: if I have to archtest a package tomorrow that needs one of the deps I merged today I don't have to recompile it. On slower archs, this really helps. Regards, Tobias -- In the future, everyone will be anonymous for 15 minutes. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
Mike Frysinger wrote: any other potential ideas ? (pretend my idea here isnt the greatest thing since Robot Chicken) Lies...nothing is better than Robot Chicken! -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 20 Jun 2007 00:47:04 -0400
Mike Frysinger [EMAIL PROTECTED] wrote:
mayhaps we need a new function to be run in src_install() to label
files as sensitive ... so baselayout would do:
esosensitive /etc/{fstab,group,passwd,shadow}
and then we expand the format of CONTENTS in the vdb:
priv /etc/fstab hash mtime
And what would be phase 2 of that? Just having a new filetype
in CONTENTS doesn't accomplish anything by itself ...
Marius
--
Marius Mauch [EMAIL PROTECTED]
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 2007-20-06 at 00:47 -0400, Mike Frysinger wrote: there are many files out there that contain critical information about your system ... however, there are certainly cases where the admin fully knows what they're doing and they want to create a binary package of their system with these sensitive files ... so where to meet in the middle. any other potential ideas ? (pretend my idea here isnt the greatest thing since Robot Chicken) I will claim that almost any file in /etc is potentially sensitive (even if it does not contain passwords, if may contain other informations interesting to a cracker). And even if we did what you propose, we'd run the risk of missing some and giving the user a false sense of security. Maybe we should document somewhere that the only way to make bin pkg that are safe for public distribution is to do emerge -b or -B .. And that pkgs built with quickpkg may contain sensitive information. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Mittwoch, 20. Juni 2007, Olivier Crête wrote: I will claim that almost any file in /etc is potentially sensitive (even if it does not contain passwords, if may contain other informations interesting to a cracker). And even if we did what you propose, we'd run the risk of missing some and giving the user a false sense of security. Maybe we should document somewhere that the only way to make bin pkg that are safe for public distribution is to do emerge -b or -B .. And that pkgs built with quickpkg may contain sensitive information. If there is smart conf-file updating inside pkg_preinst(), I think even emerge -b could be unsafe. Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 20 Jun 2007 15:15:20 +0200 Matthias Schwarzott [EMAIL PROTECTED] wrote: On Mittwoch, 20. Juni 2007, Olivier Crête wrote: I will claim that almost any file in /etc is potentially sensitive (even if it does not contain passwords, if may contain other informations interesting to a cracker). And even if we did what you propose, we'd run the risk of missing some and giving the user a false sense of security. Maybe we should document somewhere that the only way to make bin pkg that are safe for public distribution is to do emerge -b or -B .. And that pkgs built with quickpkg may contain sensitive information. If there is smart conf-file updating inside pkg_preinst(), I think even emerge -b could be unsafe. preinst is run after building the tbz2 package. Marius -- Marius Mauch [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wednesday 20 June 2007, Marius Mauch wrote:
Mike Frysinger [EMAIL PROTECTED] wrote:
mayhaps we need a new function to be run in src_install() to label
files as sensitive ... so baselayout would do:
esosensitive /etc/{fstab,group,passwd,shadow}
and then we expand the format of CONTENTS in the vdb:
priv /etc/fstab hash mtime
And what would be phase 2 of that? Just having a new filetype
in CONTENTS doesn't accomplish anything by itself ...
updating any tool that creates binary packages from the live $ROOT of course
silly billy
current behavior:
# quickpkg baselayout
* Building package for sys-apps/baselayout-1.12.10-r4
* Packages now in '/usr/portage/pacakges':
* sys-apps/baselayout-1.12.10-r4: 307K
proposed new behavior (exact output here is not part of the discussion so dont
nit pick it):
# quickpkg baselayout
* Building package for sys-apps/baselayout-1.12.10-r4
* Skipping sensitive file: /etc/passwd
* Skipping sensitive file: /etc/shadow
* Skipping sensitive file: /etc/group
* Packages now in '/usr/portage/pacakges':
* sys-apps/baselayout-1.12.10-r4: 307K
# quickpkg --iamsensitive baselayout
* Building package for sys-apps/baselayout-1.12.10-r4
* Including sensitive file: /etc/passwd
* Including sensitive file: /etc/shadow
* Including sensitive file: /etc/group
* Packages now in '/usr/portage/pacakges':
* sys-apps/baselayout-1.12.10-r4: 307K
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wednesday 20 June 2007, Olivier Crête wrote: On Wed, 2007-20-06 at 00:47 -0400, Mike Frysinger wrote: there are many files out there that contain critical information about your system ... however, there are certainly cases where the admin fully knows what they're doing and they want to create a binary package of their system with these sensitive files ... so where to meet in the middle. any other potential ideas ? (pretend my idea here isnt the greatest thing since Robot Chicken) I will claim that almost any file in /etc is potentially sensitive (even if it does not contain passwords, if may contain other informations interesting to a cracker). And even if we did what you propose, we'd run the risk of missing some and giving the user a false sense of security. dont limit yourself to /etc, we're really talking CONFIG_PROTECT ... i wanted to avoid that large envelop as there are plenty of files in there which would never be of concern (mime.types?), but perhaps it's the only sane way to go ... we say anything that is CONFIG_PROTECT-ed is (by nature) potentially sensitive rather than expanding the ebuild API to have ebuild writers explicitly mark things ... Maybe we should document somewhere that the only way to make bin pkg that are safe for public distribution is to do emerge -b or -B .. And that pkgs built with quickpkg may contain sensitive information. seriously, come on, you dont really expect people to read such things ? no reason to write off something critical like this when it can be addressed -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 20 Jun 2007 16:07:07 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: no reason to write off something critical like this when it can be addressed It can be addressed by banning binary package creation off an installed filesystem. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
Mike Frysinger kirjoitti:
On Wednesday 20 June 2007, Marius Mauch wrote:
Mike Frysinger [EMAIL PROTECTED] wrote:
mayhaps we need a new function to be run in src_install() to label
files as sensitive ... so baselayout would do:
esosensitive /etc/{fstab,group,passwd,shadow}
and then we expand the format of CONTENTS in the vdb:
priv /etc/fstab hash mtime
And what would be phase 2 of that? Just having a new filetype
in CONTENTS doesn't accomplish anything by itself ...
updating any tool that creates binary packages from the live $ROOT of course
silly billy
current behavior:
# quickpkg baselayout
* Building package for sys-apps/baselayout-1.12.10-r4
* Packages now in '/usr/portage/pacakges':
* sys-apps/baselayout-1.12.10-r4: 307K
proposed new behavior (exact output here is not part of the discussion so
dont
nit pick it):
# quickpkg baselayout
* Building package for sys-apps/baselayout-1.12.10-r4
* Skipping sensitive file: /etc/passwd
* Skipping sensitive file: /etc/shadow
* Skipping sensitive file: /etc/group
* Packages now in '/usr/portage/pacakges':
* sys-apps/baselayout-1.12.10-r4: 307K
# quickpkg --iamsensitive baselayout
* Building package for sys-apps/baselayout-1.12.10-r4
* Including sensitive file: /etc/passwd
* Including sensitive file: /etc/shadow
* Including sensitive file: /etc/group
* Packages now in '/usr/portage/pacakges':
* sys-apps/baselayout-1.12.10-r4: 307K
-mike
It would probably be prudent to have pristine versions of the files
installed on the system (optional) so that you can actually create
binary packages with all the files.
Regards,
Petteri
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
Ciaran McCreesh wrote: On Wed, 20 Jun 2007 16:07:07 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: no reason to write off something critical like this when it can be addressed It can be addressed by banning binary package creation off an installed filesystem. I'm not sure that's really a feasible solution (but then you probably weren't suggesting it with that intention). Being able to create a backup of any installed package without re-emerging is pretty handy. Many people use it and there would be a revolt if quickpkg were removed. I use FEATURES=buildpkg myself, so I've always got that backup. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wednesday 20 June 2007, Ciaran McCreesh wrote: Mike Frysinger [EMAIL PROTECTED] wrote: no reason to write off something critical like this when it can be addressed It can be addressed by banning binary package creation off an installed filesystem. there's no fun in that -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 20 Jun 2007 15:19:46 -0500 Andrew Gaffney [EMAIL PROTECTED] wrote: I'm not sure that's really a feasible solution (but then you probably weren't suggesting it with that intention). Being able to create a backup of any installed package without re-emerging is pretty handy. Many people use it and there would be a revolt if quickpkg were removed. Then live-filesystem-generated packages could be marked as 'not for redistribution'. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wednesday 20 June 2007, Petteri Räty wrote:
Mike Frysinger kirjoitti:
On Wednesday 20 June 2007, Marius Mauch wrote:
Mike Frysinger [EMAIL PROTECTED] wrote:
mayhaps we need a new function to be run in src_install() to label
files as sensitive ... so baselayout would do:
esosensitive /etc/{fstab,group,passwd,shadow}
and then we expand the format of CONTENTS in the vdb:
priv /etc/fstab hash mtime
And what would be phase 2 of that? Just having a new filetype
in CONTENTS doesn't accomplish anything by itself ...
updating any tool that creates binary packages from the live $ROOT of
course silly billy
current behavior:
# quickpkg baselayout
* Building package for sys-apps/baselayout-1.12.10-r4
* Packages now in '/usr/portage/pacakges':
* sys-apps/baselayout-1.12.10-r4: 307K
proposed new behavior (exact output here is not part of the discussion so
dont nit pick it):
# quickpkg baselayout
* Building package for sys-apps/baselayout-1.12.10-r4
* Skipping sensitive file: /etc/passwd
* Skipping sensitive file: /etc/shadow
* Skipping sensitive file: /etc/group
* Packages now in '/usr/portage/pacakges':
* sys-apps/baselayout-1.12.10-r4: 307K
# quickpkg --iamsensitive baselayout
* Building package for sys-apps/baselayout-1.12.10-r4
* Including sensitive file: /etc/passwd
* Including sensitive file: /etc/shadow
* Including sensitive file: /etc/group
* Packages now in '/usr/portage/pacakges':
* sys-apps/baselayout-1.12.10-r4: 307K
It would probably be prudent to have pristine versions of the files
installed on the system (optional) so that you can actually create
binary packages with all the files.
being able to generate binary packages that actually reflect the live $ROOT is
desirable
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 20 Jun 2007 16:27:27 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: being able to generate binary packages that actually reflect the live $ROOT is desirable Is being able to generate redistributable binary packages that reflect the live ROOT desirable? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 2007-20-06 at 21:35 +0100, Ciaran McCreesh wrote: On Wed, 20 Jun 2007 16:27:27 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: being able to generate binary packages that actually reflect the live $ROOT is desirable Is being able to generate redistributable binary packages that reflect the live ROOT desirable? Yes, it is, if you want to redistribute them to trusted parties (like other computers you own). -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
Ciaran McCreesh wrote: On Wed, 20 Jun 2007 15:19:46 -0500 Andrew Gaffney [EMAIL PROTECTED] wrote: I'm not sure that's really a feasible solution (but then you probably weren't suggesting it with that intention). Being able to create a backup of any installed package without re-emerging is pretty handy. Many people use it and there would be a revolt if quickpkg were removed. Then live-filesystem-generated packages could be marked as 'not for redistribution'. That's certainly a lot more feasible. However, it would have to be marked in some way that portage would recognize, and that marking could still likely be easily removed. This still allows the social engineering attack. Someone can get a binpkg created with quickpkg of someone else's baselayout and then remove the marking that would make portage gripe. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wednesday 20 June 2007, Ciaran McCreesh wrote: Mike Frysinger [EMAIL PROTECTED] wrote: being able to generate binary packages that actually reflect the live $ROOT is desirable Is being able to generate redistributable binary packages that reflect the live ROOT desirable? that's a feature that exists now that there's no reason to disable ... not that it can be disabled -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 20 Jun 2007 16:48:50 -0400 Olivier Crête [EMAIL PROTECTED] wrote: On Wed, 2007-20-06 at 21:35 +0100, Ciaran McCreesh wrote: On Wed, 20 Jun 2007 16:27:27 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: being able to generate binary packages that actually reflect the live $ROOT is desirable Is being able to generate redistributable binary packages that reflect the live ROOT desirable? Yes, it is, if you want to redistribute them to trusted parties (like other computers you own). Is this use case better served by install-time-generated binary packages with a way of modifying the contents? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 20 Jun 2007 16:54:34 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: On Wednesday 20 June 2007, Ciaran McCreesh wrote: Mike Frysinger [EMAIL PROTECTED] wrote: being able to generate binary packages that actually reflect the live $ROOT is desirable Is being able to generate redistributable binary packages that reflect the live ROOT desirable? that's a feature that exists now that there's no reason to disable ... not that it can be disabled I'm not suggesting forcibly disabling it, merely marking binary packages as designed for distribution or not designed for distribution, not accepting the latter on other systems and requiring explicit user action to turn the latter into the former. The specific underlying question being, what are the use cases for binary packages? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 2007-06-20 at 23:18 +0300, Petteri Räty wrote: It would probably be prudent to have pristine versions of the files installed on the system (optional) so that you can actually create binary packages with all the files. If we go that direction we could have like a --live flag to quickpkg to pull files from live file system, or from defaults stored else where or etc. Although not sure I like that idea due to extra bloat. But that's one of the few downfalls I see to that approach. I am sure others might see some I am not. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 2007-06-20 at 15:53 -0500, Andrew Gaffney wrote: This still allows the social engineering attack. Someone can get a binpkg created with quickpkg of someone else's baselayout and then remove the marking that would make portage gripe. That's providing people pay attention to portage griping in the first place. Which I would assume most don't :) Unless they have to. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wednesday 20 June 2007, Ciaran McCreesh wrote: On Wed, 20 Jun 2007 16:54:34 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: On Wednesday 20 June 2007, Ciaran McCreesh wrote: Mike Frysinger [EMAIL PROTECTED] wrote: being able to generate binary packages that actually reflect the live $ROOT is desirable Is being able to generate redistributable binary packages that reflect the live ROOT desirable? that's a feature that exists now that there's no reason to disable ... not that it can be disabled I'm not suggesting forcibly disabling it, merely marking binary packages as designed for distribution or not designed for distribution, not accepting the latter on other systems and requiring explicit user action to turn the latter into the former. The specific underlying question being, what are the use cases for binary packages? the use of the binpkg is not an issue, it's the creation ... people blindly creating tbz2's which could contain their sensitive files and posting them i'll just go ahead with the feedback from Olivier and have quickpkg skip CONFIG_PROTECT by default -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 20 Jun 2007 17:19:01 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: The specific underlying question being, what are the use cases for binary packages? the use of the binpkg is not an issue, it's the creation ... people blindly creating tbz2's which could contain their sensitive files and posting them Use cases include all aspects of use, including creation. The way binary packages are now appears to be far from ideal for any plausible use case I can think up, which is why I'm wondering whether there's a better way forward than just adding in another hack. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 2007-06-20 at 15:57 -0400, Mike Frysinger wrote:
On Wednesday 20 June 2007, Marius Mauch wrote:
Mike Frysinger [EMAIL PROTECTED] wrote:
mayhaps we need a new function to be run in src_install() to label
files as sensitive ... so baselayout would do:
esosensitive /etc/{fstab,group,passwd,shadow}
and then we expand the format of CONTENTS in the vdb:
priv /etc/fstab hash mtime
And what would be phase 2 of that? Just having a new filetype
in CONTENTS doesn't accomplish anything by itself ...
updating any tool that creates binary packages from the live $ROOT of course
silly billy
current behavior:
# quickpkg baselayout
* Building package for sys-apps/baselayout-1.12.10-r4
* Packages now in '/usr/portage/pacakges':
* sys-apps/baselayout-1.12.10-r4: 307K
proposed new behavior (exact output here is not part of the discussion so
dont
nit pick it):
# quickpkg baselayout
* Building package for sys-apps/baselayout-1.12.10-r4
* Skipping sensitive file: /etc/passwd
* Skipping sensitive file: /etc/shadow
* Skipping sensitive file: /etc/group
* Packages now in '/usr/portage/pacakges':
* sys-apps/baselayout-1.12.10-r4: 307K
# quickpkg --iamsensitive baselayout
* Building package for sys-apps/baselayout-1.12.10-r4
* Including sensitive file: /etc/passwd
* Including sensitive file: /etc/shadow
* Including sensitive file: /etc/group
* Packages now in '/usr/portage/pacakges':
* sys-apps/baselayout-1.12.10-r4: 307K
Suggestion:
If you go down this sensitive route. please ensure that the
generated.tbz2 is mode 600 to prevent exposing this sensitive
data more than need be.
--
Ned Ludd [EMAIL PROTECTED]
Gentoo Linux
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wednesday 20 June 2007, Ned Ludd wrote:
On Wed, 2007-06-20 at 15:57 -0400, Mike Frysinger wrote:
On Wednesday 20 June 2007, Marius Mauch wrote:
Mike Frysinger [EMAIL PROTECTED] wrote:
mayhaps we need a new function to be run in src_install() to label
files as sensitive ... so baselayout would do:
esosensitive /etc/{fstab,group,passwd,shadow}
and then we expand the format of CONTENTS in the vdb:
priv /etc/fstab hash mtime
And what would be phase 2 of that? Just having a new filetype
in CONTENTS doesn't accomplish anything by itself ...
updating any tool that creates binary packages from the live $ROOT of
course silly billy
current behavior:
# quickpkg baselayout
* Building package for sys-apps/baselayout-1.12.10-r4
* Packages now in '/usr/portage/pacakges':
* sys-apps/baselayout-1.12.10-r4: 307K
proposed new behavior (exact output here is not part of the discussion so
dont nit pick it):
# quickpkg baselayout
* Building package for sys-apps/baselayout-1.12.10-r4
* Skipping sensitive file: /etc/passwd
* Skipping sensitive file: /etc/shadow
* Skipping sensitive file: /etc/group
* Packages now in '/usr/portage/pacakges':
* sys-apps/baselayout-1.12.10-r4: 307K
# quickpkg --iamsensitive baselayout
* Building package for sys-apps/baselayout-1.12.10-r4
* Including sensitive file: /etc/passwd
* Including sensitive file: /etc/shadow
* Including sensitive file: /etc/group
* Packages now in '/usr/portage/pacakges':
* sys-apps/baselayout-1.12.10-r4: 307K
Suggestion:
If you go down this sensitive route. please ensure that the
generated.tbz2 is mode 600 to prevent exposing this sensitive
data more than need be.
that's a different bug which is already being addressed (and which lead me
down this line of thinking in the first place) ...
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wednesday 20 June 2007, Ciaran McCreesh wrote: Mike Frysinger [EMAIL PROTECTED] wrote: The specific underlying question being, what are the use cases for binary packages? the use of the binpkg is not an issue, it's the creation ... people blindly creating tbz2's which could contain their sensitive files and posting them Use cases include all aspects of use, including creation. extended analysis on the use cases is irrelevant in the scope of this thread -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 20 Jun 2007 17:38:22 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: On Wednesday 20 June 2007, Ciaran McCreesh wrote: Mike Frysinger [EMAIL PROTECTED] wrote: The specific underlying question being, what are the use cases for binary packages? the use of the binpkg is not an issue, it's the creation ... people blindly creating tbz2's which could contain their sensitive files and posting them Use cases include all aspects of use, including creation. extended analysis on the use cases is irrelevant in the scope of this thread No it isn't. You're talking about making a change, but you haven't established that you're changing the right thing or that the scope of your change is optimal. There's a good chance in this case that the problem you're attempting to solve is better solved by a change in a slightly different area. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wednesday 20 June 2007, Ciaran McCreesh wrote: Mike Frysinger [EMAIL PROTECTED] wrote: On Wednesday 20 June 2007, Ciaran McCreesh wrote: Mike Frysinger [EMAIL PROTECTED] wrote: The specific underlying question being, what are the use cases for binary packages? the use of the binpkg is not an issue, it's the creation ... people blindly creating tbz2's which could contain their sensitive files and posting them Use cases include all aspects of use, including creation. extended analysis on the use cases is irrelevant in the scope of this thread No it isn't. You're talking about making a change, but you haven't established that you're changing the right thing or that the scope of your change is optimal. There's a good chance in this case that the problem you're attempting to solve is better solved by a change in a slightly different area. feel free to ponder whatever you like, the issue lies purely in the creation of the tarball which is what i will address in quickpkg -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 2007-20-06 at 17:19 -0400, Mike Frysinger wrote: On Wednesday 20 June 2007, Ciaran McCreesh wrote: On Wed, 20 Jun 2007 16:54:34 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: On Wednesday 20 June 2007, Ciaran McCreesh wrote: Mike Frysinger [EMAIL PROTECTED] wrote: being able to generate binary packages that actually reflect the live $ROOT is desirable Is being able to generate redistributable binary packages that reflect the live ROOT desirable? that's a feature that exists now that there's no reason to disable ... not that it can be disabled I'm not suggesting forcibly disabling it, merely marking binary packages as designed for distribution or not designed for distribution, not accepting the latter on other systems and requiring explicit user action to turn the latter into the former. The specific underlying question being, what are the use cases for binary packages? the use of the binpkg is not an issue, it's the creation ... people blindly creating tbz2's which could contain their sensitive files and posting them i'll just go ahead with the feedback from Olivier and have quickpkg skip CONFIG_PROTECT by default This will by default create potentially broken packages (since many just wont work without their CONFIG_PROTECTed files). That's why I suggested a big fat warning and accepting that we can't protect users against themselves or against social engineering (aka their own stupidity). -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wednesday 20 June 2007, Olivier Crête wrote: On Wed, 2007-20-06 at 17:19 -0400, Mike Frysinger wrote: the use of the binpkg is not an issue, it's the creation ... people blindly creating tbz2's which could contain their sensitive files and posting them i'll just go ahead with the feedback from Olivier and have quickpkg skip CONFIG_PROTECT by default This will by default create potentially broken packages (since many just wont work without their CONFIG_PROTECTed files). That's why I suggested a big fat warning and accepting that we can't protect users against themselves or against social engineering (aka their own stupidity). i think this would only be an issue where quickpkg is being run non-interactively and the output not being reviewed (which i also dont think is a common scenario for quickpkg) ... the new output of quickpkg will be explicit in what it is (or isnt) doing so there wont be any issue of drive by social engineering as for dubbing people who are successfully socially engineered stupid, i dont really think that's appropriate ... consider noobs on irc in #gentoo who just want to help and havent learned their way around yet. are they stupid (well they might be, but lets give them the benefit of the doubt) ? i'd liken the situation to a kid growing up ... kids arent stupid, they lack experience and calling them stupid isnt constructive -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 2007-06-20 at 22:01 +0100, Ciaran McCreesh wrote: The specific underlying question being, what are the use cases for binary packages? Ever managed a network of multiple Gentoo identical Gentoo machines? Compiling the exact same packages with the exact same USE/C(XX)FLAGS/LDFLAGS/etc on multiple machines is an egregious waste of resources, especially in a corporate environment where maintenance windows simply aren't large enough to allow for a multiple-hour compile job to run. Plus, who keeps GCC on their production servers, anyway? ;] -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 20 Jun 2007 15:31:32 -0700 Chris Gianelloni [EMAIL PROTECTED] wrote: On Wed, 2007-06-20 at 22:01 +0100, Ciaran McCreesh wrote: The specific underlying question being, what are the use cases for binary packages? Ever managed a network of multiple Gentoo identical Gentoo machines? That's one use case, yes. Now what are the others? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 2007-20-06 at 18:28 -0400, Mike Frysinger wrote: On Wednesday 20 June 2007, Olivier Crête wrote: On Wed, 2007-20-06 at 17:19 -0400, Mike Frysinger wrote: the use of the binpkg is not an issue, it's the creation ... people blindly creating tbz2's which could contain their sensitive files and posting them i'll just go ahead with the feedback from Olivier and have quickpkg skip CONFIG_PROTECT by default This will by default create potentially broken packages (since many just wont work without their CONFIG_PROTECTed files). That's why I suggested a big fat warning and accepting that we can't protect users against themselves or against social engineering (aka their own stupidity). i think this would only be an issue where quickpkg is being run non-interactively and the output not being reviewed (which i also dont think is a common scenario for quickpkg) ... the new output of quickpkg will be explicit in what it is (or isnt) doing so there wont be any issue of drive by social engineering Well, I often use quickpkg when I want to try a new version of a package (I quickpkg the currently installed one.. and I want to keep all the config files). Then I emerge the new one, and I absolutely want to be able to restore the config files if I want to revert to an older version, either because they have been broken by the pkg_postinst or something else. I still haven't heard a good reason to change anything thats not the printing in quickpkg. as for dubbing people who are successfully socially engineered stupid, i dont really think that's appropriate ... consider noobs on irc in #gentoo who just want to help and havent learned their way around yet. are they stupid (well they might be, but lets give them the benefit of the doubt) ? i'd liken the situation to a kid growing up ... kids arent stupid, they lack experience and calling them stupid isnt constructive I'm not calling anyone stupid... but I'm talking of our inner stupidity (which we all have)... -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
Ciaran McCreesh wrote: On Wed, 20 Jun 2007 15:31:32 -0700 Chris Gianelloni [EMAIL PROTECTED] wrote: On Wed, 2007-06-20 at 22:01 +0100, Ciaran McCreesh wrote: The specific underlying question being, what are the use cases for binary packages? Ever managed a network of multiple Gentoo identical Gentoo machines? That's one use case, yes. Now what are the others? Preparing binaries for really small boxes, you prepare a single basic image and then provide a binhost to handle updates and optional packages. again, same cflags/useflags/targets. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wednesday 20 June 2007, Olivier Crête wrote: On Wed, 2007-20-06 at 18:28 -0400, Mike Frysinger wrote: On Wednesday 20 June 2007, Olivier Crête wrote: On Wed, 2007-20-06 at 17:19 -0400, Mike Frysinger wrote: the use of the binpkg is not an issue, it's the creation ... people blindly creating tbz2's which could contain their sensitive files and posting them i'll just go ahead with the feedback from Olivier and have quickpkg skip CONFIG_PROTECT by default This will by default create potentially broken packages (since many just wont work without their CONFIG_PROTECTed files). That's why I suggested a big fat warning and accepting that we can't protect users against themselves or against social engineering (aka their own stupidity). i think this would only be an issue where quickpkg is being run non-interactively and the output not being reviewed (which i also dont think is a common scenario for quickpkg) ... the new output of quickpkg will be explicit in what it is (or isnt) doing so there wont be any issue of drive by social engineering Well, I often use quickpkg when I want to try a new version of a package (I quickpkg the currently installed one.. and I want to keep all the config files). Then I emerge the new one, and I absolutely want to be able to restore the config files if I want to revert to an older version, either because they have been broken by the pkg_postinst or something else. I still haven't heard a good reason to change anything thats not the printing in quickpkg. i didnt say i was going to be disallowing this, i said i'd be making it no longer the default behavior ... what you want to do will still be perfectly possible as for dubbing people who are successfully socially engineered stupid, i dont really think that's appropriate ... consider noobs on irc in #gentoo who just want to help and havent learned their way around yet. are they stupid (well they might be, but lets give them the benefit of the doubt) ? i'd liken the situation to a kid growing up ... kids arent stupid, they lack experience and calling them stupid isnt constructive I'm not calling anyone stupid... but I'm talking of our inner stupidity (which we all have)... ah, zen stupidity -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
Ciaran McCreesh wrote: what are the use cases for binary packages? Apart from those already mentioned by Chris, I use FEATURES=buildpkg to be able to recover from a catastrophic experiment with a package's content, for being able to quickly reinstall it. Although it's lame, it's pretty easy to run `emerge -K foo` to get vanilla config files. Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 2007-06-20 at 23:35 +0100, Ciaran McCreesh wrote: On Wed, 20 Jun 2007 15:31:32 -0700 Chris Gianelloni [EMAIL PROTECTED] wrote: On Wed, 2007-06-20 at 22:01 +0100, Ciaran McCreesh wrote: The specific underlying question being, what are the use cases for binary packages? Ever managed a network of multiple Gentoo identical Gentoo machines? That's one use case, yes. Now what are the others? Release building... Backups... Testing newer packages... Oh yeah,and who said we really needed more than one use case? I think providing tools to allow Gentoo to be adopted in the corporate environment is reason enough to have binary package support, and I feel that many people will agree with me. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 2007-06-20 at 18:50 -0400, Mike Frysinger wrote: Well, I often use quickpkg when I want to try a new version of a package (I quickpkg the currently installed one.. and I want to keep all the config files). Then I emerge the new one, and I absolutely want to be able to restore the config files if I want to revert to an older version, either because they have been broken by the pkg_postinst or something else. I still haven't heard a good reason to change anything thats not the printing in quickpkg. i didnt say i was going to be disallowing this, i said i'd be making it no longer the default behavior ... what you want to do will still be perfectly possible Is quickpkg a candidate for FEATURES? I'd much prefer this be able to be controlled by a configuration file (and overridden on the command line) so I don't have to remember to put --iamsureidontcareaboutsecurity or whatever on the command line every time. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 2007-06-20 at 16:08 -0700, Chris Gianelloni wrote: On Wed, 2007-06-20 at 23:35 +0100, Ciaran McCreesh wrote: On Wed, 20 Jun 2007 15:31:32 -0700 Chris Gianelloni [EMAIL PROTECTED] wrote: On Wed, 2007-06-20 at 22:01 +0100, Ciaran McCreesh wrote: The specific underlying question being, what are the use cases for binary packages? Ever managed a network of multiple Gentoo identical Gentoo machines? That's one use case, yes. Now what are the others? Release building... Backups... Testing newer packages... Oh yeah,and who said we really needed more than one use case? I think providing tools to allow Gentoo to be adopted in the corporate environment is reason enough to have binary package support, and I feel that many people will agree with me. The issue isn't whether or not we should have them, or for that matter whether or not there is more then one use case. The issue is making sure that we know what the use cases are to ensure that the tools we have are flexible enough to be able to support every case and so that we don't paint ourselves into a corner by making decisions before we know how people plan on using the tool. At least that is how I see it... --Dan signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 20 Jun 2007 16:08:33 -0700 Chris Gianelloni [EMAIL PROTECTED] wrote: That's one use case, yes. Now what are the others? Release building... Backups... Testing newer packages... Now expand upon those. Oh yeah,and who said we really needed more than one use case? If you make your design decisions based upon a single use case, your design will probably suck when people try to use it for anything else. Since people clearly are using binary packages for at least three different things, all of those three things need to be considered. I think providing tools to allow Gentoo to be adopted in the corporate environment is reason enough to have binary package support, and I feel that many people will agree with me. You miss my point. I'm not saying binaries are useless. I'm saying you should establish all of what they're used for before making changes. A change that improves binary packages for one use case may make them less ideal for others. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wednesday 20 June 2007, Chris Gianelloni wrote: On Wed, 2007-06-20 at 18:50 -0400, Mike Frysinger wrote: Well, I often use quickpkg when I want to try a new version of a package (I quickpkg the currently installed one.. and I want to keep all the config files). Then I emerge the new one, and I absolutely want to be able to restore the config files if I want to revert to an older version, either because they have been broken by the pkg_postinst or something else. I still haven't heard a good reason to change anything thats not the printing in quickpkg. i didnt say i was going to be disallowing this, i said i'd be making it no longer the default behavior ... what you want to do will still be perfectly possible Is quickpkg a candidate for FEATURES? I'd much prefer this be able to be controlled by a configuration file (and overridden on the command line) so I don't have to remember to put --iamsureidontcareaboutsecurity or whatever on the command line every time. there's a new quickpkg default opts ala emerge default opts env var -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
Ciaran McCreesh wrote: On Wed, 20 Jun 2007 15:19:46 -0500 Andrew Gaffney [EMAIL PROTECTED] wrote: I'm not sure that's really a feasible solution (but then you probably weren't suggesting it with that intention). Being able to create a backup of any installed package without re-emerging is pretty handy. Many people use it and there would be a revolt if quickpkg were removed. Then live-filesystem-generated packages could be marked as 'not for redistribution'. That's probably a good idea if only because there are certain binaries that we're not allowed to redistribute...things like Firefox with certain USE flags, or freetype with the better hinter. Neither of these can be redistributed in binary form with certain USE flags; Firefox will have to ship without its proper name, and freetype will have to use the sucky -- er, magically more free -- hinter. @vapier: Do potential licensing/copyright issues like these factor into your proposal in any way? wolf31o2 mentioned installing several identical boxes simultaneously using the same redistributed binaries, but in the case of these two packages, if they're built with -bindist on the live filesystem, redistributing it as-is isn't allowed. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wednesday 20 June 2007, Josh Saddler wrote: Do potential licensing/copyright issues like these factor into your proposal in any way? no, that's an exercise for the user and no one else ... there's no way i'd have the tools prevent this. about the only thing i'd add is a reminder message if binpkg is in IUSE and not in USE. wolf31o2 mentioned installing several identical boxes simultaneously using the same redistributed binaries, but in the case of these two packages, if they're built with -bindist on the live filesystem, redistributing it as-is isn't allowed. wolf is free to redstribute his binary packages among his machines all he likes regardless of USE=bindist -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wednesday 20 June 2007, Mike Frysinger wrote: On Wednesday 20 June 2007, Josh Saddler wrote: Do potential licensing/copyright issues like these factor into your proposal in any way? no, that's an exercise for the user and no one else ... there's no way i'd have the tools prevent this. about the only thing i'd add is a reminder message if binpkg is in IUSE and not in USE. i like this idea so it's been added: # quickpkg pycrypto * dev-python/pycrypto-2.0.1-r5: package was emerged with USE=-bindist! * dev-python/pycrypto-2.0.1-r5: it may not be legal to redistribute this. * Building package for dev-python/pycrypto-2.0.1-r5 ...[ ok ] * Packages now in '/usr/portage/packages': * dev-python/pycrypto-2.0.1-r5: 188K -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
Mike Frysinger wrote: On Wednesday 20 June 2007, Mike Frysinger wrote: On Wednesday 20 June 2007, Josh Saddler wrote: Do potential licensing/copyright issues like these factor into your proposal in any way? no, that's an exercise for the user and no one else ... there's no way i'd have the tools prevent this. about the only thing i'd add is a reminder message if binpkg is in IUSE and not in USE. i like this idea so it's been added: # quickpkg pycrypto * dev-python/pycrypto-2.0.1-r5: package was emerged with USE=-bindist! * dev-python/pycrypto-2.0.1-r5: it may not be legal to redistribute this. * Building package for dev-python/pycrypto-2.0.1-r5 ...[ ok ] * Packages now in '/usr/portage/packages': * dev-python/pycrypto-2.0.1-r5: 188K -mike Cool, thanks for adding the warning to quickpkg. signature.asc Description: OpenPGP digital signature
[gentoo-dev] how to handle sensitive files when generating binary packages
there are many files out there that contain critical information about your
system ... lets look at /etc/shadow
baselayout installs this file, yet it is not listed in CONTENTS for a very
good reason ... if someone were to run `quickpkg baselayout` and post the
file somewhere, they could easily have done so without realizing the
implications. social engineering on irc for example would be trivial to
accomplish this and say hello to my little root shell.
however, there are certainly cases where the admin fully knows what they're
doing and they want to create a binary package of their system with these
sensitive files ... so where to meet in the middle.
mayhaps we need a new function to be run in src_install() to label files
as sensitive ... so baselayout would do:
esosensitive /etc/{fstab,group,passwd,shadow}
and then we expand the format of CONTENTS in the vdb:
priv /etc/fstab hash mtime
any other potential ideas ? (pretend my idea here isnt the greatest thing
since Robot Chicken)
-mike
signature.asc
Description: This is a digitally signed message part.
