Re: [gentoo-dev] Re: Devmanual text on ChangeLogs
On 01-05-2011 19:43:48 -0400, Rich Freeman wrote: My personal feeling is that we should keep the changelogs as-is, and include removals, until we're on git. Then we should re-evaluate. git doesn't magically solve all the problems! -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Re: Devmanual text on ChangeLogs
2011-05-02 02:16:49 Markos Chandras napisał(a): On Sun, May 01, 2011 at 04:31:08PM -0700, Brian Harring wrote: On Sun, May 01, 2011 at 11:23:40PM +, Duncan wrote: What about having a dedicated server-based changlog-signing key? That's still a lot of signing with a single key, but as you observed, the hazards of a loss of integrity there aren't as high as with most of the tree content. It'd require changes, but I don't believe they're out of line with that required for the rest of the proposal. It means the only real trust that clients can level is on that key- since it will be the last signer (thus /the/ signer) across all pkgs. Get at that key, and you've got the tree, versus the current form, crack all signing keys and you've got the tree. Mind you this is ignoring eclasses, but getting eclasses sorted will be mildly pointless if the rest of the solution has been weakened/gutted since. Point is, it's not *just* about having a signature on it- it's about mapping the trust of that signature back, and sectioning/containing compromises. What y'all are suggesting guts that layered defense. ~brian Then the only choice here is to ignore Changelogs from Manifests and live with that. You have your changelogs unprotected but you keep your ebuilds safe(?). As I said, it is a balanced choice that has to be made. Generated ChangeLogs could contain server-side-generated signatures for themselves (gpg --sign --clearsign ChangeLog mv ChangeLog.asc ChangeLog). (Manifests wouldn't contain entries for ChangeLogs.) -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Devmanual text on ChangeLogs
Fabian Groffen posted on Sun, 01 May 2011 12:00:17 +0200 as excerpted: Attachment not shown: MIME type chemical/x-genbank; filename ChangeLog.gen Had to laugh at that one. =:^) -- 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
Re: [gentoo-dev] Re: Devmanual text on ChangeLogs
On 01-05-2011 14:55:24 +, Duncan wrote: Fabian Groffen posted on Sun, 01 May 2011 12:00:17 +0200 as excerpted: Attachment not shown: MIME type chemical/x-genbank; filename ChangeLog.gen Had to laugh at that one. =:^) Apologies, the .gen extension apparently made the MIME match to this thing I'd never heard before. You can just open it as normal text file, though. -- Fabian Groffen Gentoo on a different level
[gentoo-dev] Re: Devmanual text on ChangeLogs
Markos Chandras posted on Sun, 01 May 2011 22:08:31 +0100 as excerpted: Having the servers do that, will also allow us to provide cut down Changelogs ( lets say keep that last 10 entries ) so we can provide a more minimal portage tree, size wise. What about cutting it to the largest whole number of entries that can fit in 4 KB, since many filesystems use 4 KB blocks anyway, with files always taking a whole number of blocks? If the file's going to use 4 KB anyway, might as well take advantage of it. Taking a look at the top of my last synced portage changelog as what's likely an example from the verbose end, that's thirteen entries, here, plus the header at the top. For most packages I imagine it'd be something like 20 entries. (Yes, I know some filesystems don't have that restriction and in fact use one myself, but if we're going for some arbitrary file size, 4 KB is about as reasonable a choice as it gets, precisely /because/ that's the default block size for so many widely used fss.) -- 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] Re: Devmanual text on ChangeLogs
Markos Chandras posted on Sun, 01 May 2011 23:49:06 +0100 as excerpted: On Sun, May 01, 2011 at 03:33:25PM -0700, Brian Harring wrote: On Sun, May 01, 2011 at 10:08:31PM +0100, Markos Chandras wrote: Since most ( if not all ) of us use the same message on the Changelog and on the commit log, it probably worth the effort of having the rsync servers create the Changelogs before populate the portage tree. This opens up a bit of nastyness; either the service would have to resign all manifests (which defeats a fair bit of the signing intent), or ChangeLog's would have to pulled in full from cvs, generated strictly server side (else manifest will have stale chksums for it), and ChangeLog will have to exist outside of all validation. Thats a fair point but the way I see it we need to make a balanced choice. Obviously is not feasible to have the rsync servers resign everything. [But] having all the gpg keys on the rsync servers [...] doesn't look that smart to me. Leaving Changelogs unprotected might be a bit of a trouble but it certainly is not that big a deal. Nothing serious can happen if someone hijacks a plain text file. In case people want to ensure end-to-end point integrity, we can use a separate GPG key for the rsync server. However, this will make our GPG keys useless, and having a single key to sing 10.000 Manifest files does not look good either. What about having a dedicated server-based changlog-signing key? That's still a lot of signing with a single key, but as you observed, the hazards of a loss of integrity there aren't as high as with most of the tree content. It'd require changes, but I don't believe they're out of line with that required for the rest of the proposal. -- 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
Re: [gentoo-dev] Re: Devmanual text on ChangeLogs
On Sun, May 01, 2011 at 11:23:40PM +, Duncan wrote: What about having a dedicated server-based changlog-signing key? That's still a lot of signing with a single key, but as you observed, the hazards of a loss of integrity there aren't as high as with most of the tree content. It'd require changes, but I don't believe they're out of line with that required for the rest of the proposal. It means the only real trust that clients can level is on that key- since it will be the last signer (thus /the/ signer) across all pkgs. Get at that key, and you've got the tree, versus the current form, crack all signing keys and you've got the tree. Mind you this is ignoring eclasses, but getting eclasses sorted will be mildly pointless if the rest of the solution has been weakened/gutted since. Point is, it's not *just* about having a signature on it- it's about mapping the trust of that signature back, and sectioning/containing compromises. What y'all are suggesting guts that layered defense. ~brian pgpjF9q9h6E0S.pgp Description: PGP signature
Re: [gentoo-dev] Re: Devmanual text on ChangeLogs
On Sun, May 1, 2011 at 7:31 PM, Brian Harring ferri...@gmail.com wrote: Get at that key, and you've got the tree, versus the current form, crack all signing keys and you've got the tree. Well, more like get any one of the keys and you get the tree, since portage only validates that a trusted key signed a package, and not that the key belonged to the package maintainer. In any case, the whole way that manifest signing works does not really preserve a signature from end-to-end. If I sign three files and somebody else signs two files, they end up overwriting my signature. So, if a mirror checks all the sigs, makes a change, and re-signs with its own key that isn't much less secure than what we have now. I wouldn't actually distribute the work all the way to the mirrors though - I'd have a central server generate the changelogs, sign them, and then propagate that to the mirror network. You just need to protect that one server really well then. If you really want to have dev-user trust with no broken links then the signatures would need to be associated with each file - not just the whole manifest. Plus, the local portage would need to check the metadata cache for consistency. In any case, I see manifest signing as a relatively minor issue here. It seems like the more fundamental debate is how much metadata we really should be distributing all the way to end-user systems, vs keeping it in a repository like a cvs log. Sure, offline access is useful, but the question is whether it is useful enough. My personal feeling is that we should keep the changelogs as-is, and include removals, until we're on git. Then we should re-evaluate. Rich
Re: [gentoo-dev] Re: Devmanual text on ChangeLogs
On Sun, May 01, 2011 at 07:43:48PM -0400, Rich Freeman wrote: On Sun, May 1, 2011 at 7:31 PM, Brian Harring ferri...@gmail.com wrote: Get at that key, and you've got the tree, versus the current form, crack all signing keys and you've got the tree. My personal feeling is that we should keep the changelogs as-is, and include removals, until we're on git. Then we should re-evaluate. Rich Git migration won't happen anytime soon. Why postpone the problem instead of mitigating it? The solution can easily be migrated to git if needed. Regards, -- Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 pgpj18sf8lIFv.pgp Description: PGP signature
Re: [gentoo-dev] Re: Devmanual text on ChangeLogs
On Sun, May 01, 2011 at 04:31:08PM -0700, Brian Harring wrote: On Sun, May 01, 2011 at 11:23:40PM +, Duncan wrote: What about having a dedicated server-based changlog-signing key? That's still a lot of signing with a single key, but as you observed, the hazards of a loss of integrity there aren't as high as with most of the tree content. It'd require changes, but I don't believe they're out of line with that required for the rest of the proposal. It means the only real trust that clients can level is on that key- since it will be the last signer (thus /the/ signer) across all pkgs. Get at that key, and you've got the tree, versus the current form, crack all signing keys and you've got the tree. Mind you this is ignoring eclasses, but getting eclasses sorted will be mildly pointless if the rest of the solution has been weakened/gutted since. Point is, it's not *just* about having a signature on it- it's about mapping the trust of that signature back, and sectioning/containing compromises. What y'all are suggesting guts that layered defense. ~brian Then the only choice here is to ignore Changelogs from Manifests and live with that. You have your changelogs unprotected but you keep your ebuilds safe(?). As I said, it is a balanced choice that has to be made. Regards, -- Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 pgpggJYfi62pV.pgp Description: PGP signature
[gentoo-dev] Re: Devmanual text on ChangeLogs
Rich Freeman posted on Sun, 01 May 2011 19:43:48 -0400 as excerpted: On Sun, May 1, 2011 at 7:31 PM, Brian Harring ferri...@gmail.com wrote: Get at that key, and you've got the tree, versus the current form, crack all signing keys and you've got the tree. Well, more like get any one of the keys and you get the tree, since portage only validates that a trusted key signed a package, and not that the key belonged to the package maintainer. OK, so everything in a manifest signs together, and if the changelog as-is gets server-signed, so does the rest of the manifest. I see the problem there, but there are ways around it. As I said, changes may be necessary, but they aren't huge compared to the scope of the whole idea. What about having the server-generated changelogs separate from the rest of the package, say in a changelogs dir, one such dir per category with for example portage's changelog then located at sys-apps/changelogs/portage, thus preventing between-category naming collisions (we've been there!)? Then the server could generate and sign the changelogs without interfering with the package manifests and their signatures. The changelogs would all be signed by the same key, but it wouldn't be used for signing anything else, thus not interfering with actual package security at all. -- 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] Re: Devmanual text on ChangeLogs
Il giorno sab, 30/04/2011 alle 11.07 +0200, Ulrich Mueller ha scritto: I won't clutter ChangeLogs with useless entries for whitespace changes or spelling fixes in comments, for example. They already account for a considerable (too large?) percentage of the portage tree [1], and we shouldn't blow them up further by adding useless information. If you read the last paragraph in my suggestion was to cycle the logs... -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: Devmanual text on ChangeLogs
On 14:28 Sat 30 Apr , Diego Elio Pettenò wrote: If you read the last paragraph in my suggestion was to cycle the logs... Maybe this would be better together with a mechanism (automatic?) to keep the complete ChangeLogs (as they are now) somewhere (but not in the main tree). Sometimes, full history/ChangeLog can be useful, eg. when you want to see quickly how old a package in the tree is, or find bug numbers of fixes you may want to recheck etc etc. -- Panagiotis Christopoulos ( pchrist ) ( Gentoo Lisp Project ) pgp07fj0BJKHE.pgp Description: PGP signature
Re: [gentoo-dev] Re: Devmanual text on ChangeLogs
On 4/30/11 3:05 PM, Panagiotis Christopoulos wrote: On 14:28 Sat 30 Apr , Diego Elio Pettenò wrote: If you read the last paragraph in my suggestion was to cycle the logs... Maybe this would be better together with a mechanism (automatic?) to keep the complete ChangeLogs (as they are now) somewhere (but not in the main tree). Sometimes, full history/ChangeLog can be useful, eg. when you want to see quickly how old a package in the tree is, or find bug numbers of fixes you may want to recheck etc etc. Seconded. I sometimes read entire ChangeLogs, for example for abandoned packages or packages I suspect to be abandoned, sometimes I read them for fun, and so on. I'm fine with shipping a trimmed down versions to users, but I think the full version must be easy to access. A possible solution would be to truncate the logs in the cvs-rsync migration. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Devmanual text on ChangeLogs
On Sat, Apr 30, 2011 at 9:44 AM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: I'm fine with shipping a trimmed down versions to users, but I think the full version must be easy to access. If the changelogs were accessible via a predicable URL then a simple command-line tool or portage option might display them on request. echangeinfo cat/pkg is probably no harder for the average end-user to type than less /usr/portage/cat/pkg/ChangeLog. Rich
