Bug#595728: git-core: permissions of templates too restrictive
Hi, * The Anarcat [2010-09-22 00:32]: > On Wed, Sep 22, 2010 at 01:16:39AM +0300, Jonathan Nieder wrote: [...] > > * would set a weird precedent for errata that did not come about in > > fixing a security-related bug > > The regression was introduce by fixing a security-related bug which was > bundled in a stable point-release instead of a regular security upgrade > (which is a source of confusion for me in the first place). > > > If I ran the world or had infinite time, I'd suggest a stable point > > release with just the binnmu, which has none of those problems. > > > > Release managers: would that or something similar be feasible? > > Thanks for the time taken to consider my objections. Can we (security team) release such a binNMU through a second revision of this DSA? I'm really not sure what the proper way would be but right now that is the one making the most sense to me. Cheers Nico -- Nico Golde - http://www.ngolde.de - n...@jabber.ccc.de - GPG: 0xA0A0 For security reasons, all text in this mail is double-rot13 encrypted. pgpJqlmri3PBV.pgp Description: PGP signature
Bug#595728: git-core: permissions of templates too restrictive
On Wed, Sep 22, 2010 at 01:16:39AM +0300, Jonathan Nieder wrote: > (+cc: previous participants) > > The Anarcat wrote: > > > I understand that, but how does that keep us from issuing [an] > > update on security.debian.org? > [...] > > People running stable are not necessarily running volatile and s-p-u. > > Ah, I missed your point before. Keeping git broken in lenny is indeed > a lousy outcome. > > So what can we do instead? > > Uploading to security.debian.org, though at first it seems pragmatic, > has problems: > * doesn't help installations without security.debian.org in > sources.list (which is a reasonable configuration in some special > circumstances, really!). I think there are more people running with security.d.o than volatile.d.o or backports. In fact, i fail to see how *not* running with security.d.o would be a proper configuration. > * would be terribly confusing to people watching security.debian.org I'm not sure why. > * would set a weird precedent for errata that did not come about in > fixing a security-related bug The regression was introduce by fixing a security-related bug which was bundled in a stable point-release instead of a regular security upgrade (which is a source of confusion for me in the first place). > If I ran the world or had infinite time, I'd suggest a stable point > release with just the binnmu, which has none of those problems. > > Release managers: would that or something similar be feasible? Thanks for the time taken to consider my objections. -- Antoine Beaupré Réseau Koumbit Networks +1.514.387.6262 signature.asc Description: Digital signature
Bug#595728: git-core: permissions of templates too restrictive
(+cc: previous participants) The Anarcat wrote: > I understand that, but how does that keep us from issuing [an] > update on security.debian.org? [...] > People running stable are not necessarily running volatile and s-p-u. Ah, I missed your point before. Keeping git broken in lenny is indeed a lousy outcome. So what can we do instead? Uploading to security.debian.org, though at first it seems pragmatic, has problems: * doesn't help installations without security.debian.org in sources.list (which is a reasonable configuration in some special circumstances, really!). * would be terribly confusing to people watching security.debian.org * would set a weird precedent for errata that did not come about in fixing a security-related bug If I ran the world or had infinite time, I'd suggest a stable point release with just the binnmu, which has none of those problems. Release managers: would that or something similar be feasible? Thanks again and sorry for the trouble, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#595728: git-core: permissions of templates too restrictive
On Fri, Sep 10, 2010 at 15:48:37 +0200, Axel Beckert wrote: > Will it come to stable only with the next minor release in a few > months or will there be an earlier propagation to stable? > stable doesn't change outside of point releases (that would break Release.gpg, for one thing). Cheers, Julien signature.asc Description: Digital signature
Bug#595728: git-core: permissions of templates too restrictive
On Fri, Sep 10, 2010 at 03:48:37PM +0200, Axel Beckert wrote: > Philipp Kern wrote on Tue, 7 Sep 2010 01:43:09 +0200: > > I scheduled a binNMU. A quick fix is to upgrade to the version in > > proposed-updates when it's available there latest tomorrow evening. > > The binNMU is on the mirrors in proposed-updates for a few days now > and it works as expected. > > Will it come to stable only with the next minor release in a few > months or will there be an earlier propagation to stable? > > I suggest to push it to stable as soon as possible, as "git init" and > therefore also "git clone" are unusable on i386 stable since the last > upload which is quite some regression within stable itself. The only option we have would be to use volatile[1]. That would mean to do a sourceful upload to volatile-master, with a version number greater than what's in stable and less than the binNMU (leaving +a[...] or +b1~volatile)... Kind regards, Philipp Kern [1] Or scheduling another point release very soon. signature.asc Description: Digital signature
Bug#595728: git-core: permissions of templates too restrictive
Hi, Philipp Kern wrote on Tue, 7 Sep 2010 01:43:09 +0200: > I scheduled a binNMU. A quick fix is to upgrade to the version in > proposed-updates when it's available there latest tomorrow evening. The binNMU is on the mirrors in proposed-updates for a few days now and it works as expected. Will it come to stable only with the next minor release in a few months or will there be an earlier propagation to stable? I suggest to push it to stable as soon as possible, as "git init" and therefore also "git clone" are unusable on i386 stable since the last upload which is quite some regression within stable itself. Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#595728: git-core: permissions of templates too restrictive
On Tue, Sep 07, 2010 at 10:30:03AM +0200, Philipp Kern wrote: > > Thanks for the analysis. Do you think it would be worth > > cherry-picking > > the fix from v1.6.0.3~81^2 (Fix permission bits on sources checked > > out > > with an overtight umask, 2008-08-21[1]) to lenny to prevent this > > from > > happening again? > > [1] http://repo.or.cz/w/git.git/commitdiff/d8bdc49 > > yeah, I think so. Could you please an upload based on the Lenny > package? On Tue, Sep 07, 2010 at 06:01:46AM -0500, Jonathan Nieder wrote: > Nico Golde wrote: > > I'm wondering what this was. I'm building in a clean chroot and to > > be honest I have no idea what went wrong. The umask in this chroot > > is 022. > > Hmm, odd. Do you unpack from within the chroot or are the sources > unpacked in advance? > > You can find a package designed to avoid permissions problems at > > git://repo.or.cz/debian-git/jrn.git for-lenny > > http://mentors.debian.net/debian/pool/main/g/git-core/git-core_1.5.6.5-3+lenny4.dsc > > in case that is helpful for experimenting. It simply applies the > upstream patch [1]. Hi, as expected ;), the packages Jonathan prepared look correct. Shall I upload them to stable or proposed-updates or so? Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#595728: git-core: permissions of templates too restrictive
Hi, * Jonathan Nieder [2010-09-07 13:12]: > Nico Golde wrote: > > > I'm wondering what this was. I'm building in a clean chroot and to be > > honest I > > have no idea what went wrong. The umask in this chroot is 022. > > Hmm, odd. Do you unpack from within the chroot or are the sources > unpacked in advance? Within the chroot but I can't recall if I did by accident unpack from outside. Given my umask is 027 this would explain it. Cheers Nico -- Nico Golde - http://www.ngolde.de - n...@jabber.ccc.de - GPG: 0xA0A0 For security reasons, all text in this mail is double-rot13 encrypted. pgp74kT4sHGjC.pgp Description: PGP signature
Bug#595728: git-core: permissions of templates too restrictive
Nico Golde wrote: > I'm wondering what this was. I'm building in a clean chroot and to be honest > I > have no idea what went wrong. The umask in this chroot is 022. Hmm, odd. Do you unpack from within the chroot or are the sources unpacked in advance? You can find a package designed to avoid permissions problems at git://repo.or.cz/debian-git/jrn.git for-lenny http://mentors.debian.net/debian/pool/main/g/git-core/git-core_1.5.6.5-3+lenny4.dsc in case that is helpful for experimenting. It simply applies the upstream patch [1]. Sorry I missed this before. Regards, Jonathan [1] http://git.kernel.org/?p=git/git.git;a=commitdiff_plain;h=d8bdc49265559786533d7f7377b2c39038dd6309 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#595728: git-core: permissions of templates too restrictive
Hi, * Philipp Kern [2010-09-07 11:25]: > On Mon, Sep 06, 2010 at 12:56:05AM -0500, Adam Mercer wrote: [...] > Thanks for the bug report. Indeed the git-core package is broken on > lenny/i386 since the last point release on Saturday. Sadly nobody caught > that bug when the package was in proposed-updates. It's only i386, that's > affected, because of oddities on the uploader's build machine. The autobuilt > ones look fine. I'm wondering what this was. I'm building in a clean chroot and to be honest I have no idea what went wrong. The umask in this chroot is 022. > I scheduled a binNMU. A quick fix is to upgrade to the version in > proposed-updates when it's available there latest tomorrow evening. Thanks! Sorry for the inconvenience... Cheers Nico -- Nico Golde - http://www.ngolde.de - n...@jabber.ccc.de - GPG: 0xA0A0 For security reasons, all text in this mail is double-rot13 encrypted. pgpYN0gLQV9e4.pgp Description: PGP signature
Bug#595728: git-core: permissions of templates too restrictive
Hi, On Mon, Sep 06, 2010 at 10:55:32PM -0500, Jonathan Nieder wrote: > Philipp Kern wrote: > > Thanks for the bug report. Indeed the git-core package is broken on > > lenny/i386 since the last point release on Saturday. Sadly nobody caught > > that bug when the package was in proposed-updates. It's only i386, that's > > affected, because of oddities on the uploader's build machine. The > > autobuilt > > ones look fine. > > > > I scheduled a binNMU. > Thanks for the analysis. Do you think it would be worth cherry-picking > the fix from v1.6.0.3~81^2 (Fix permission bits on sources checked out > with an overtight umask, 2008-08-21[1]) to lenny to prevent this from > happening again? > [1] http://repo.or.cz/w/git.git/commitdiff/d8bdc49 yeah, I think so. Could you please an upload based on the Lenny package? Kind regards, Philipp Kern signature.asc Description: Digital signature
Bug#595728: git-core: permissions of templates too restrictive
Hi Philipp, Philipp Kern wrote: > Thanks for the bug report. Indeed the git-core package is broken on > lenny/i386 since the last point release on Saturday. Sadly nobody caught > that bug when the package was in proposed-updates. It's only i386, that's > affected, because of oddities on the uploader's build machine. The autobuilt > ones look fine. > > I scheduled a binNMU. Thanks for the analysis. Do you think it would be worth cherry-picking the fix from v1.6.0.3~81^2 (Fix permission bits on sources checked out with an overtight umask, 2008-08-21[1]) to lenny to prevent this from happening again? [1] http://repo.or.cz/w/git.git/commitdiff/d8bdc49 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#595728: git-core: permissions of templates too restrictive
On Mon, Sep 06, 2010 at 12:56:05AM -0500, Adam Mercer wrote: > Since the last update of git-core the templates in /usr/share/git-core are > marked with permissions -rw-r- (owned by root:root), so general users > can't access them. Therefore when a new repository is cloned the process > failed as permission is denied to copy the template files into the new cloned > repo. Marking these files as readable by others allows the clone to proceed. > > -- System Information: > Debian Release: 5.0.6 > APT prefers stable > APT policy: (500, 'stable') > Architecture: i386 (i686) Thanks for the bug report. Indeed the git-core package is broken on lenny/i386 since the last point release on Saturday. Sadly nobody caught that bug when the package was in proposed-updates. It's only i386, that's affected, because of oddities on the uploader's build machine. The autobuilt ones look fine. I scheduled a binNMU. A quick fix is to upgrade to the version in proposed-updates when it's available there latest tomorrow evening. Sorry Philipp Kern signature.asc Description: Digital signature
Bug#595728: git-core: permissions of templates too restrictive
Package: git-core Version: 1:1.5.6.5-3+lenny3.1 Severity: grave Justification: renders package unusable Since the last update of git-core the templates in /usr/share/git-core are marked with permissions -rw-r- (owned by root:root), so general users can't access them. Therefore when a new repository is cloned the process failed as permission is denied to copy the template files into the new cloned repo. Marking these files as readable by others allows the clone to proceed. -- System Information: Debian Release: 5.0.6 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-486 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages git-core depends on: ii libc6 2.7-18lenny4 GNU C Library: Shared libraries ii libcurl3-gnutls7.18.2-8lenny4Multi-protocol file transfer libra ii libdigest-sha1-perl2.11-2+b1 NIST SHA-1 message digest algorith ii liberror-perl 0.17-1Perl module for error/exception ha ii libexpat1 2.0.1-4+lenny3XML parsing C library - runtime li ii perl-modules 5.10.0-19lenny2 Core Perl modules ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime Versions of packages git-core recommends: ii less 418-1 Pager program similar to more ii openssh-client [ssh-client] 1:5.1p1-5 secure shell client, an rlogin/rsh ii patch 2.5.9-5Apply a diff file to an original ii rsync 3.0.3-2fast remote file copy program (lik Versions of packages git-core suggests: pn git-arch (no description available) pn git-cvs(no description available) pn git-daemon-run (no description available) pn git-doc(no description available) pn git-email (no description available) pn git-gui(no description available) pn git-svn(no description available) pn gitk (no description available) pn gitweb (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
