[gentoo-dev] how to handle sensitive files when generating binary packages

[gentoo-dev] how to handle sensitive files when generating binary packages

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Andrew Gaffney]

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
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Marius Mauch]

On Wed, 20 Jun 2007 00:47:04 -0400
Mike Frysinger <vapier@gentoo.org> 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 <genone@gentoo.org>
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] VDB Changes (Was Re: how to handle sensitive files when generating binary packages)

[Steve Long]

Marius Mauch wrote:
> Mike Frysinger <vapier@gentoo.org> 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.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]

On Wednesday 20 June 2007, Marius Mauch wrote:
> Mike Frysinger <vapier@gentoo.org> 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1755 bytes --]

Mike Frysinger kirjoitti:
> On Wednesday 20 June 2007, Marius Mauch wrote:
>> Mike Frysinger <vapier@gentoo.org> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1952 bytes --]

On Wednesday 20 June 2007, Petteri Räty wrote:
> Mike Frysinger kirjoitti:
> > On Wednesday 20 June 2007, Marius Mauch wrote:
> >> Mike Frysinger <vapier@gentoo.org> 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 300 bytes --]

On Wed, 20 Jun 2007 16:27:27 -0400
Mike Frysinger <vapier@gentoo.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 507 bytes --]

On Wed, 2007-20-06 at 21:35 +0100, Ciaran McCreesh wrote:
> On Wed, 20 Jun 2007 16:27:27 -0400
> Mike Frysinger <vapier@gentoo.org> 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
tester@gentoo.org
Gentoo Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 689 bytes --]

On Wed, 20 Jun 2007 16:48:50 -0400
Olivier Crête <tester@gentoo.org> wrote:
> On Wed, 2007-20-06 at 21:35 +0100, Ciaran McCreesh wrote:
> > On Wed, 20 Jun 2007 16:27:27 -0400
> > Mike Frysinger <vapier@gentoo.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 411 bytes --]

On Wednesday 20 June 2007, Ciaran McCreesh wrote:
> Mike Frysinger <vapier@gentoo.org> 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 875 bytes --]

On Wed, 20 Jun 2007 16:54:34 -0400
Mike Frysinger <vapier@gentoo.org> wrote:
> On Wednesday 20 June 2007, Ciaran McCreesh wrote:
> > Mike Frysinger <vapier@gentoo.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]

On Wednesday 20 June 2007, Ciaran McCreesh wrote:
> On Wed, 20 Jun 2007 16:54:34 -0400
>
> Mike Frysinger <vapier@gentoo.org> wrote:
> > On Wednesday 20 June 2007, Ciaran McCreesh wrote:
> > > Mike Frysinger <vapier@gentoo.org> 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 629 bytes --]

On Wed, 20 Jun 2007 17:19:01 -0400
Mike Frysinger <vapier@gentoo.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 503 bytes --]

On Wednesday 20 June 2007, Ciaran McCreesh wrote:
> Mike Frysinger <vapier@gentoo.org> 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

On Wed, 20 Jun 2007 17:38:22 -0400
Mike Frysinger <vapier@gentoo.org> wrote:
> On Wednesday 20 June 2007, Ciaran McCreesh wrote:
> > Mike Frysinger <vapier@gentoo.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1119 bytes --]

On Wednesday 20 June 2007, Ciaran McCreesh wrote:
> Mike Frysinger <vapier@gentoo.org> wrote:
> > On Wednesday 20 June 2007, Ciaran McCreesh wrote:
> > > Mike Frysinger <vapier@gentoo.org> 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 1661 bytes --]

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 <vapier@gentoo.org> wrote:
> > > On Wednesday 20 June 2007, Ciaran McCreesh wrote:
> > > > Mike Frysinger <vapier@gentoo.org> 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
tester@gentoo.org
Gentoo Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 2181 bytes --]

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
tester@gentoo.org
Gentoo Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 2433 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 737 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 394 bytes --]

On Wed, 20 Jun 2007 15:31:32 -0700
Chris Gianelloni <wolf31o2@gentoo.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Luca Barbato]

Ciaran McCreesh wrote:
> On Wed, 20 Jun 2007 15:31:32 -0700
> Chris Gianelloni <wolf31o2@gentoo.org> 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
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 921 bytes --]

On Wed, 2007-06-20 at 23:35 +0100, Ciaran McCreesh wrote:
> On Wed, 20 Jun 2007 15:31:32 -0700
> Chris Gianelloni <wolf31o2@gentoo.org> 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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Daniel Ostrow]

[-- Attachment #1: Type: text/plain, Size: 1292 bytes --]

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 <wolf31o2@gentoo.org> 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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: how to handle sensitive files when generating binary packages

[Steve Long]

>> 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.)


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]

On Wed, 20 Jun 2007 16:08:33 -0700
Chris Gianelloni <wolf31o2@gentoo.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Tobias Klausmann]

Hi! 

On Wed, 20 Jun 2007, Ciaran McCreesh wrote:
> On Wed, 20 Jun 2007 15:31:32 -0700
> Chris Gianelloni <wolf31o2@gentoo.org> 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.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 421 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 604 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Ned Ludd]

On Wed, 2007-06-20 at 15:57 -0400, Mike Frysinger wrote:
> On Wednesday 20 June 2007, Marius Mauch wrote:
> > Mike Frysinger <vapier@gentoo.org> 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 <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 2022 bytes --]

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 <vapier@gentoo.org> 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]

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
tester@gentoo.org
Gentoo Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Matthias Schwarzott]

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)
--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: how to handle sensitive files when generating binary packages

[Duncan]

Matthias Schwarzott <zzam@gentoo.org> posted
200706201515.20684.zzam@gentoo.org, 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

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Marius Mauch]

On Wed, 20 Jun 2007 15:15:20 +0200
Matthias Schwarzott <zzam@gentoo.org> 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 <genone@gentoo.org>
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1632 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 276 bytes --]

On Wed, 20 Jun 2007 16:07:07 -0400
Mike Frysinger <vapier@gentoo.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Andrew Gaffney]

Ciaran McCreesh wrote:
> On Wed, 20 Jun 2007 16:07:07 -0400
> Mike Frysinger <vapier@gentoo.org> 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
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 492 bytes --]

On Wed, 20 Jun 2007 15:19:46 -0500
Andrew Gaffney <agaffney@gentoo.org> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Andrew Gaffney]

Ciaran McCreesh wrote:
> On Wed, 20 Jun 2007 15:19:46 -0500
> Andrew Gaffney <agaffney@gentoo.org> 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
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] User warnings (Was Re: how to handle sensitive files when generating binary packages)

[Steve Long]

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.


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: how to handle sensitive files when generating binary packages

[Steve Long]

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


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Josh Saddler]

[-- Attachment #1: Type: text/plain, Size: 1268 bytes --]

Ciaran McCreesh wrote:
> On Wed, 20 Jun 2007 15:19:46 -0500
> Andrew Gaffney <agaffney@gentoo.org> 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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 720 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 771 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Josh Saddler]

[-- Attachment #1: Type: text/plain, Size: 889 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Ned Ludd]

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 <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Vlastimil Babka]

-----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-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Vlastimil Babka]

-----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-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 475 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] how to handle sensitive files when generating binary packages

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 299 bytes --]

On Wednesday 20 June 2007, Ciaran McCreesh wrote:
> Mike Frysinger <vapier@gentoo.org> 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]