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
[gentoo-dev] VDB Changes (Was Re: how to handle sensitive files when generating binary packages)
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 ... I imagine the tools need updating to deal with that (especially quickpkg etc.) Of course this needs to be tested thoroughly from a security pov, and admins may well decide they don't like the idea (after all a professional is going to have their own backup procedures in place already.) If you're adding a priv field, tho, you might as well make it a generic attributes field imo. Not sure what uses you can come up with, but rcs integration springs to mind. On a wider note, how difficult are these sorts of changes to implement? Only we were discussing a satisfiedBy addition to refine system updates on #-portage (something to do with slots, unversioned deps and --depclean, but I couldn't really follow it all) and that would require change in vdb as well, which I was told needed an EAPI bump. So, if y'all are discussing vdb changes for EAPI=1 (which aiui is needed yesterday ;) I for one would love to know what other changes devs would like to see. -- [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
[gentoo-dev] New developer: Ali Polatel (hawking)
It's my usual pleasure to introduce to you Ali hawking Polatel who will be joining us to help with the netmon stuff. Ali hails us from Turkey. He is currently a physics engineering stupid in the Istanbul Technical University and a real wizard in chess. He is the National Master to be more exact. Please give him the usual warm welcome and try to beat him in online chess. Regards, Petteri -- Gentoo/Recruiters lead signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: how to handle sensitive files when generating binary packages
Matthias Schwarzott [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Wed, 20 Jun 2007 15:15:20 +0200: 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. If so, then something is broken. pkg_preinst is for stuff done to the /live/ file system (as opposed to the fake install, which is what's packaged), according to the ebuild (5) manpage. As such, it should be done when the binary package is actually merged (qmerged), since said binary package may be (and often is) installed to a system other than the one it was compiled on. If pkg_preinst is modifying as-shipped bin-pkg config files based on the live filesystem of the build system, not the target system, something's seriously broken. If it's not, then it's not unsafe after all, at least not in this context. In this regard, -b/-B behavior should be identical. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New developer: Ali Polatel (hawking)
Welcome Ali! And no, I don't think I will challenge you in chess any time soon. :) -Joe Petteri Räty wrote: It's my usual pleasure to introduce to you Ali hawking Polatel who will be joining us to help with the netmon stuff. Ali hails us from Turkey. He is currently a physics engineering stupid in the Istanbul Technical University and a real wizard in chess. He is the National Master to be more exact. Please give him the usual warm welcome and try to beat him in online chess. Regards, Petteri -- Gentoo/Recruiters lead -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New developer: Ali Polatel (hawking)
On Wednesday, June 20, 2007 06:54:42 PM Petteri Räty wrote: It's my usual pleasure to introduce to you Ali hawking Polatel who [...] is the National Master to be more exact. Where's Deep Blue when you need it?! ;-) Welcome, Ali! Best regards, Wulf pgpElUXKlArWC.pgp Description: PGP signature
Re: [gentoo-dev] New developer: Ali Polatel (hawking)
On Wed, 2007-06-20 at 19:14 +0200, Wulf C. Krueger wrote: On Wednesday, June 20, 2007 06:54:42 PM Petteri Räty wrote: It's my usual pleasure to introduce to you Ali hawking Polatel who [...] is the National Master to be more exact. Where's Deep Blue when you need it?! ;-) Wasn't built for playing chess, it's purpose has already been served, 42. Now nothing left to do but watch TV :) Welcome aboard Ali from Istanbul, not Constantinople. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New developer: Ali Polatel (hawking)
On Wed, 2007-06-20 at 19:54 +0300, Petteri Räty wrote: It's my usual pleasure to introduce to you Ali hawking Polatel who will be joining us to help with the netmon stuff. Ali hails us from Turkey. He is currently a physics engineering stupid in the Istanbul Contrary to popular opinion, I am going to go with ^ student and not stupid :) We will save the stupid till after a few commits ;) Ali, hope you brought your sense of humor with you. -- 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, 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] New developer: Ali Polatel (hawking)
Petteri Räty wrote: It's my usual pleasure to introduce to you Ali hawking Polatel who will be joining us to help with the netmon stuff. Ali hails us from Turkey. He is currently a physics engineering stupid in the Istanbul Technical University and a real wizard in chess. He is the National Master to be more exact. Ohh, so he must be also a good teacher ^^ Please give him the usual warm welcome and try to beat him in online chess. Sounds quite tempting... Welcome, thank you for joining gentoo =) lu - now I need a go teacher... -- 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 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] New developer: Ali Polatel (hawking)
welcome here too ;) i assume Petteri means to apply sed s/stupid/student/ ? ;) unfortunately i didn't play chess in way too long so i now suck :( -- Thomas Raschbacher http://www.lordvan.com quote who=Joe Peterson Welcome Ali! And no, I don't think I will challenge you in chess any time soon. :) -Joe Petteri Räty wrote: It's my usual pleasure to introduce to you Ali hawking Polatel who will be joining us to help with the netmon stuff. Ali hails us from Turkey. He is currently a physics engineering stupid in the Istanbul Technical University and a real wizard in chess. He is the National Master to be more exact. Please give him the usual warm welcome and try to beat him in online chess. Regards, Petteri -- Gentoo/Recruiters lead -- [EMAIL PROTECTED] mailing list -- [EMAIL PROTECTED] mailing list
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] New developer: Ali Polatel (hawking)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Raschbacher - LordVan - Gentoo wrote: i assume Petteri means to apply sed s/stupid/student/ ? ;) I assume that too. Wonder what would Freud say about this mistake :) I think Petteri is also a student himself :) Anyway, welcome Ali :) - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGeaJOtbrAj05h3oQRAi3lAJwKducWie0CgqMwZeXN4aI3apvBUwCffgF7 6PX1hIR+D1jEg4+dwU9p6+4= =P7os -END PGP SIGNATURE- -- [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: 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.
[gentoo-dev] Re: how to handle sensitive files when generating binary 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. Well I'm sure you'll be over the moon to know I do ;) 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. Agreed, but the actual mechanism in question is only adds functionality; nothing is being taken away aiui. As to it borking use cases, surely it's better to explain which use case it breaks than get into a nitpick about whether there might be any others. After all that's why there's an externally-facing list: so people can chime in with their concerns. The discussion on default policy doesn't change the fact that it is a needed mechanism, imo. Having it as a switch in FEATURES makes a lot of sense, and i think that ensuring Gentoo systems won't leak sensitive information, unless explicitly told to, is a worthwhile objective. A warning when adding sensitive files to a binpkg seems like a wise idea, especially if it is a set and forget flag. (Devs can always tweak an env var, users who've lost data are harder to mollify.) -- [EMAIL PROTECTED] mailing list
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
[gentoo-dev] User warnings (Was Re: how to handle sensitive files when generating binary packages)
William L. Thomson Jr. wrote: That's providing people pay attention to portage griping in the first place. Which I would assume most don't :) Unless they have to. That's why I posted that script a few months ago: http://forums.gentoo.org/viewtopic-t-546828.html It's updated for bash 3.2 and has been tested extensively (\r seems to mess up under screen though.) Just don't run it with sh, as it needs full bash capability. We're looking at bashrc to make it more efficient, but I mainly want USE flag editing within the interface (and pkgcore compatibility.) I never miss any warnings now :-) And yeah, I would love it if i didn't need this script, but for now I still do. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: how to handle sensitive files when generating binary packages
Andrew Gaffney wrote: Ciaran McCreesh wrote: Andrew Gaffney 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. It's more feasible than banning the creation of packages from a running system, that's true. The original solution doesn't seem so infeasible to me though.. I have a feeling this is more about an alternative bin format ;) 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. Agreed. As a user, I'd much rather just be able to quickpkg whenever I choose, and know that the system will not allow sensitive files to be copied. Starting with /etc/shadow and the like is great by me, as I'm fairly sure there'll be a sensible plain-text config file I can edit by hand if I need to. If I were to allow such files to be copied, I'd like a warning. Yes I mess up sometimes, so what? I'm the user, it's expected ;p -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: New developer: Ali Polatel (hawking)
Petteri Räty wrote: It's my usual pleasure to introduce to you Ali hawking Polatel who will be joining us to help with the netmon stuff. Ali hails us from Turkey. He is currently a physics engineering stupid in the Istanbul Technical University and a real wizard in chess. He is the National Master to be more exact. Please give him the usual warm welcome and try to beat him in online chess. That's the game with the horseys right? Welcome to Gentoo! -- dirtyepic salesman said this vacuum's guaranteed gentoo org it could suck an ancient virus from the sea 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New developer: Ali Polatel (hawking)
On K, 2007-06-20 at 19:54 +0300, Petteri Räty wrote: It's my usual pleasure to introduce to you Ali hawking Polatel who will be joining us to help with the netmon stuff. Welcome Ali! Ali hails us from Turkey. He is currently a physics engineering stupid in the Istanbul Technical University and a real wizard in chess. He is the National Master to be more exact. Please give him the usual warm welcome and try to beat him in online chess. Do you appear on FICS too? :) I'd be happy to take you on, but get beaten anyway. I've played with the local national masters around here and get beaten. Hard. ;p Would be an honor to get defeated from the Turkish Master as well, but who knows how'd the challenge go ;) Cheers and welcome again, Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio -- [EMAIL PROTECTED] mailing list
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