Hi Russ,
Am Thu, Jun 13, 2024 at 01:54:16PM -0700 schrieb Russ Allbery:
>
> It would be nice to not do this on the tag2upload server, though, to
> maintain some security separation.
ACK.
> Given all of that, I think it would be more promising to look into a
> deeper integration with Salsa to
> On 6/14/24 00:50, Russ Allbery wrote:
>> This is why people are working on incremental improvements. I think
>> such improvements are more likely to get us closer to where we want to
>> be than a boil-the-ocean approach that attempts wholesale change to how
>> Debian works. It's easy to come
Hi,
On 6/14/24 00:50, Russ Allbery wrote:
We have several 90% solutions of mapping Debian packaging onto git, but
all of these are incomplete and annoying to use because we disagree with
git on what constitutes data, and what constitutes metadata, so the data
model does not match reality or
Hello,
On Thu 13 Jun 2024 at 04:13pm +01, Simon McVittie wrote:
> On Thu, 13 Jun 2024 at 15:08:15 +0100, Ian Jackson wrote:
>> I think it is possible that there will be a handful of packages where
>> things are significantly more awkward, which might not be able to
>> adopt tag2upload.
>
> This
Russ Allbery writes:
> Or, of course, find a way to disable the author/committer checks, which I
> suspect are most of the failures, and keep the object hash checks.
Apologies, I should have done a bit more research before sending my
message. Adding the following to my .gitconfig allows me to
Simon Josefsson writes:
> I have had that settings in my .gitconfig for several years, and the
> number of git repositories that fail to clone with it is not negligible.
> I encourage people to enable it and experiment for themselves. Try
> https://git.savannah.gnu.org/git/coreutils.git for
Russ Allbery writes:
>> Can this be substantiated? Using SHA1CD in Git does not necessarily
>> mean someone cannot manually create a Git repository with a colliding
>> git commit somewhere in the history that gets accepted by git, and
>> allows someone to replace actual file contents. That may
Hello,
On Fri 14 Jun 2024 at 04:42am +09, Mike Hommey wrote:
> On Thu, Jun 13, 2024 at 08:28:28PM +0800, Sean Whitton wrote:
>> Hello,
>>
>> On Wed 12 Jun 2024 at 03:45pm +01, Simon McVittie wrote:
>>
>> > As far as I know, git-archive (and therefore git-deborig) doesn't guarantee
>> > that
> "Russ" == Russ Allbery writes:
Russ> The attack that Simon is talking about doesn't require a
Russ> preimage attack, only a successful collision attack against
Russ> Git trees using SHAttered plus some assumptions about where
Russ> Git may be lazy about revalidating hashes.
Andreas Tille writes:
> From a user perspective some intermediate binary build wouldn't be more
> difficult, thought.
It would be nice to not do this on the tag2upload server, though, to
maintain some security separation.
I think it's possible to avoid running arbitrary code from the package
Marco d'Itri writes:
> si...@josefsson.org wrote:
>> Can this be substantiated? Using SHA1CD in Git does not necessarily
>> mean someone cannot manually create a Git repository with a colliding
>> git commit somewhere in the history that gets accepted by git, and
>> allows someone to replace
Hi Ian,
Am Thu, Jun 13, 2024 at 12:47:35PM +0100 schrieb Ian Jackson:
> Andreas Tille writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> > That means some package build process is done before the source
> > package is forwarded to dak and sends some e-mail back?
>
> Only a source
Sean Whitton dijo [Thu, Jun 13, 2024 at 05:42:25AM +0800]:
> > Actually, we can set acls on fingerprints and then that key wont be able
> > to upload anymore. That is not something recorded in the keyrings or the
> > DM list. Obviously that is not something used often (really really
> > seldom),
Thank you very much for this review! You were one of the people I most
wanted to hear from, since I know you have substantial expertise in the
cryptography parts of this and a lot of security experience. I know you
also had concerns in the past about hash collisions specifically.
Simon
On Thu, Jun 13, 2024 at 08:28:28PM +0800, Sean Whitton wrote:
> Hello,
>
> On Wed 12 Jun 2024 at 03:45pm +01, Simon McVittie wrote:
>
> > As far as I know, git-archive (and therefore git-deborig) doesn't guarantee
> > that repeatedly archiving the same git tree produces the same tarball,
> >
Le jeudi, 13 juin 2024, 08.23:45 h CEST Thomas Goirand a écrit :
> One thing I really dislike, is having a single gpg key to upoload them
> all. I very much preferred the design that Didier explained during
> Debconf Kosovo, where the .changes signature is uploaded together with
> the tagged
si...@josefsson.org wrote:
>Can this be substantiated? Using SHA1CD in Git does not necessarily
>mean someone cannot manually create a Git repository with a colliding
>git commit somewhere in the history that gets accepted by git, and
>allows someone to replace actual file contents. That may be
Simon Richter writes:
> We might get additional insights after a breach, perhaps, if Github
> decide to take a compromised repository offline and our copy is still
> accessible.
I think this is way more useful than you are making it sound. Upstream
may not use GitHub at all and instead use
Scott Kitterman writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> On June 13, 2024 3:02:48 PM UTC, Joerg Jaspert wrote:
> >I think this is a minor issue, actually. It does not happen often. For
> >the time it will, we can have something like "ftpmaster pushes a list of
>
On Thu, 13 Jun 2024 at 15:08:15 +0100, Ian Jackson wrote:
> I think it is possible that there will be a handful of packages where
> things are significantly more awkward, which might not be able to
> adopt tag2upload.
This would presumably be the same minority of packages where maintainers
use a
Simon Richter writes:
> Hi,
>
> On 6/13/24 22:27, Simon Josefsson wrote:
>
>> Generally I reach the same conclusion, although I think there are real
>> security problems with both the existing and the proposed tag2upload
>> mechanism that we should all be aware of. It is acceptable to realize
Antoine Beaupré writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> Well, isn't tag2upload part of dgit? Or at least git-debpush, the binary
> package, seems to be part of the dgit source package here... we're also
> talking frequently about dgit.debian.org as part of this
Hi,
* Luca Boccassi [2024-06-13 14:51]:
I was not, I wasn't suggesting to make this a hard requirement, as
you say that's more complicated. Merely moving the fire-and-forget
webhook as the last stage of the pipeline, as the default
setting/setup/config/whatever. This is not to provide strong
Scott Kitterman writes:
> I agree that this isn't a major design issue, but I think it is
> something that I think needs to be addressed before deployment of
> tag2upload. The need is certainly rare, but when it's needed, it's
> needed because it's important.
I don't understand why this would
On June 13, 2024 3:02:48 PM UTC, Joerg Jaspert wrote:
>On 17259 March 1977, Ian Jackson wrote:
>
>>> Thanks. Then possibly it is sufficient for ftpmaster just to disable
>>> tag2upload's whole key until the keyring update is pushed.
>> I'm not sure this is a sufficient answer. We don't want
On 17259 March 1977, Ian Jackson wrote:
Thanks. Then possibly it is sufficient for ftpmaster just to disable
tag2upload's whole key until the keyring update is pushed.
I'm not sure this is a sufficient answer. We don't want uploads by
revoked keys to appear on *.dgit.d.o either.
Joerg, is
Antoine Beaupré writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> On 2024-06-13 12:38:36, Ian Jackson wrote:
> > Antoine Beaupré writes ("Re: [RFC] General Resolution to deploy
> > tag2upload"):
> >> 3. what does this mean for salsa/jenkins/bts/etc?
> >
> > Nothing.
...
> > I don't
On Thu, 13 Jun 2024 at 14:34, Timo Röhling wrote:
>
> Hi,
>
> * Luca Boccassi [2024-06-13 14:23]:
> >As far as I understand in the current proposal the trigger is a
> >webhook running on Salsa after a push - have you considered instead
> >having the trigger be a stage in the salsa-ci pipeline,
Simon Richter writes ("Re: [RFC] General Resolution to deploy tag2upload [and 1
more messages]"):
> On 6/13/24 20:29, Marco d'Itri wrote:
> > Of course: this makes auditing much easier.
>
> That is a *massive* amount of data though, especially if we're expected
> to import the entire upstream
Hello,
On Thu 13 Jun 2024 at 03:11pm +02, Pierre-Elliott Bécue wrote:
> Sean Whitton wrote on 13/06/2024 at 14:44:57+0200:
>
>> Hello,
>>
>> On Thu 13 Jun 2024 at 01:05pm +02, Ansgar wrote:
>>
>>> The statement also reads like the implementation was reviewed by Russ
>>> which as far as I
On 2024-06-13 12:38:36, Ian Jackson wrote:
> Antoine Beaupré writes ("Re: [RFC] General Resolution to deploy tag2upload"):
>> Right now my workflow is basically git-buildpackage + salsa + dput,
>> relunctantly using pristine-tar sometimes.
>
>> I have *tried* to use dgit, but [...]
>
> I think
Hi,
On 6/13/24 22:27, Simon Josefsson wrote:
Generally I reach the same conclusion, although I think there are real
security problems with both the existing and the proposed tag2upload
mechanism that we should all be aware of. It is acceptable to realize
that we cannot protect against all
Russ Allbery writes:
> The decision on whether to adopt tag2upload should be made primarily on
> non-security grounds.
Generally I reach the same conclusion, although I think there are real
security problems with both the existing and the proposed tag2upload
mechanism that we should all be
On Thu, 13 Jun 2024 at 14:49, Ian Jackson
wrote:
>
> Timo Röhling writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> > Luca Boccassi [2024-06-13 14:23]:
> > >As far as I understand in the current proposal the trigger is a
> > >webhook running on Salsa after a push - have you
Timo Röhling writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> Luca Boccassi [2024-06-13 14:23]:
> >As far as I understand in the current proposal the trigger is a
> >webhook running on Salsa after a push - have you considered instead
> >having the trigger be a stage in the salsa-ci
Hi,
On 6/13/24 20:29, Marco d'Itri wrote:
Do we actually want or need to hoard all the collaboration history?
Of course: this makes auditing much easier.
That is a *massive* amount of data though, especially if we're expected
to import the entire upstream git history as well and base the
Luca Boccassi writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> As far as I understand in the current proposal the trigger is a
> webhook running on Salsa after a push - have you considered instead
> having the trigger be a stage in the salsa-ci pipeline, that would run
> after the
Hi,
* Luca Boccassi [2024-06-13 14:23]:
As far as I understand in the current proposal the trigger is a
webhook running on Salsa after a push - have you considered instead
having the trigger be a stage in the salsa-ci pipeline, that would run
after the previous stages have completed
On Thu, 13 Jun 2024 at 12:47, Ian Jackson
wrote:
>
> Andreas Tille writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> > That means some package build process is done before the source
> > package is forwarded to dak and sends some e-mail back?
>
> Only a source package build.
As far
Sean Whitton wrote on 13/06/2024 at 14:44:57+0200:
> Hello,
>
> On Thu 13 Jun 2024 at 01:05pm +02, Ansgar wrote:
>
>> The statement also reads like the implementation was reviewed by Russ
>> which as far as I understand isn't the case either? Or do you only plan
>> to deploy a version once
Hello,
On Thu 13 Jun 2024 at 01:05pm +02, Ansgar wrote:
> The statement also reads like the implementation was reviewed by Russ
> which as far as I understand isn't the case either? Or do you only plan
> to deploy a version once such a review happened?
We weren't planning for this to be done,
On Thu, 13 Jun 2024 at 12:02, Ian Jackson
wrote:
>
> Sean Whitton writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> >[Joerg Jaspert wrote:]
> >> Actually, we can set acls on fingerprints and then that key wont be able
> >> to upload anymore. That is not something recorded in the
Hi Ian,
On 6/13/24 18:57, Ian Jackson wrote:
(Because git inherently has history, the dgit-repos server can
perform both functions at once.)
Do we actually want or need to hoard all the collaboration history?
Simon
Hello,
On Wed 12 Jun 2024 at 03:45pm +01, Simon McVittie wrote:
> As far as I know, git-archive (and therefore git-deborig) doesn't guarantee
> that repeatedly archiving the same git tree produces the same tarball,
> which could be awkward for the ftp archive's tarball-integrity-based rules;
>
Hello,
On Thu 13 Jun 2024 at 01:05pm +02, Ansgar wrote:
> On Thu, 2024-06-13 at 16:58 +0800, Sean Whitton wrote:
>> On Wed 12 Jun 2024 at 11:14am +02, Ansgar wrote:
>> >
>> > As far as I understand, the GR is about pushing the design and
>> > implementation as is, without any changes. It
Jonathan Carter writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> On 2024/06/12 10:21, Luca Boccassi wrote:
> > Having a separate namespace with strong ACLs seems exactly what you
> > want, even if it duplicates the individual repositories (the backend
> > git store deduplicates it
Andreas Tille writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> That means some package build process is done before the source
> package is forwarded to dak and sends some e-mail back?
Only a source package build.
> I know we have this. My point is that tag2upload users might
Antoine Beaupré writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> Right now my workflow is basically git-buildpackage + salsa + dput,
> relunctantly using pristine-tar sometimes.
> I have *tried* to use dgit, but [...]
I think maybe I should make a blog post explaining what dgit
s...@debian.org wrote:
>Do we actually want or need to hoard all the collaboration history?
Of course: this makes auditing much easier.
--
ciao,
Marco
On Thu, 2024-06-13 at 16:58 +0800, Sean Whitton wrote:
> On Wed 12 Jun 2024 at 11:14am +02, Ansgar wrote:
> >
> > As far as I understand, the GR is about pushing the design and
> > implementation as is, without any changes. It very explicitly says
> > so.
>
> It does not say this.
Quote:
---
Aigars Mahinovs writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> Correct me if I am wrong, but if we are looking at dgit.d.o as
> snapshot and audit log of the tag2upload service, would it not be
> beneficial for the auditing and back-tracing process to actually
> keep the code that
Simon Richter writes ("Re: [RFC] General Resolution to deploy tag2upload [and 1
more messages]"):
> On 6/13/24 18:57, Ian Jackson wrote:
> > (Because git inherently has history, the dgit-repos server can
> > perform both functions at once.)
>
> Do we actually want or need to hoard all the
Timo Röhling writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> Considering that tag2upload is supposed to become a critical
> component of our infrastructure, I am missing (or may have
> overlooked) some information on how the deployment is going to be
> maintained.
>
> I assume
Scott Kitterman writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> If I am understanding you correctly, tag2upload is only relevant to the XZ
> Utils type attack if the maintainer uses the upstream git rather than the
> upstream provided tarball as the basis for their Debian work.
Bastian Blank writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> On Wed, Jun 12, 2024 at 04:23:29PM +0100, Simon McVittie wrote:
> > On Wed, 12 Jun 2024 at 15:20:45 +0100, Ian Jackson wrote:
> > > tag2upload, like dgit, ensures and insists that the git tree you are
> > > uploading
Sean Whitton writes ("Re: [RFC] General Resolution to deploy tag2upload"):
>[Joerg Jaspert wrote:]
>> Actually, we can set acls on fingerprints and then that key wont be able
>> to upload anymore. That is not something recorded in the keyrings or the
>> DM list. Obviously that is not something
Hi Sean,
Am Thu, Jun 13, 2024 at 04:53:56PM +0800 schrieb Sean Whitton:
> > thanks to all for this GR. I like tag2upload in principle. The only
> > thing I'm a bit scared about is that it simplifies uploading something
> > that was never built before on the local machine. Sure, this can be
> >
Hello Sean,
first of all, I have been a very happy user of dgit for some time
now, and I want to use the opportunity to thank Ian and you for your
excellent work. I consider dgit to be one of two major improvements
to my packaging workflow (the other being sbuild with unshare
backend), and I
On Wed, 12 Jun 2024 at 16:20, Jonas Smedegaard wrote:
> To answer your convoluted question, I am suggesting that Salsa and
> tag2upload has very different needs (multi-user write versus multi-user
> append-only, drastically simplified), and consequently to not argue that
> reuse of Salsa for
Hello,
On Thu 13 Jun 2024 at 10:33am +02, Andreas Tille wrote:
> thanks to all for this GR. I like tag2upload in principle. The only
> thing I'm a bit scared about is that it simplifies uploading something
> that was never built before on the local machine. Sure, this can be
> done with
Hello,
On Wed 12 Jun 2024 at 04:23pm +01, Simon McVittie wrote:
> On Wed, 12 Jun 2024 at 15:20:45 +0100, Ian Jackson wrote:
>> tag2upload, like dgit, ensures and insists that the git tree you are
>> uploading corresponds precisely [1] to the generated source package.
>>
>> If you base your
Hello,
On Wed 12 Jun 2024 at 09:42am -07, Russ Allbery wrote:
> Bastian Blank writes:
>
>> If we need a design, then we can easily avoid the problem points. There
>> is a working counter proposal open:
>
>> https://bblank.thinkmo.de/introducing-uploads-debian-git.html
>
> It requires a
Hello,
On Thu 13 Jun 2024 at 08:23am +02, Thomas Goirand wrote:
> One thing I really dislike, is having a single gpg key to upoload them all. I
> very much preferred the design that Didier explained during Debconf Kosovo,
> where the .changes signature is uploaded together with the tagged
Hi,
Luca Boccassi wrote on 12/06/2024 at 13:15:47+0200:
> On Wed, 12 Jun 2024 at 12:03, Jonas Smedegaard wrote:
>>
>> Quoting Luca Boccassi (2024-06-12 12:28:21)
>> > On Wed, 12 Jun 2024 at 09:35, Jonas Smedegaard wrote:
>> > >
>> > > Quoting Luca Boccassi (2024-06-12 10:21:40)
>> > > > On
Hello,
On Wed 12 Jun 2024 at 11:14am +02, Ansgar wrote:
> Hi,
>
> On Wed, 2024-06-12 at 08:59 +0200, Holger Levsen wrote:
>> Am Tue, Jun 11, 2024 at 10:27:56PM -0700 schrieb Russ Allbery:
>> > > As I said several times before: the implementation has known
>> > > security
>> > > bugs (unless
Hello,
On Thu 13 Jun 2024 at 12:08am +02, Joerg Jaspert wrote:
> On 17258 March 1977, Sean Whitton wrote:
>
So there is no change here.
>>> Actually, we can set acls on fingerprints and then that key wont be able
>>> to upload anymore. That is not something recorded in the keyrings or the
Hello,
On Wed 12 Jun 2024 at 11:18am -06, Gunnar Wolf wrote:
> I am mentioning this because I see quite a bit of friction in this
> regard. Some people see your tag2upload proposal as a step to diminish
> Salsa's place in Debian and probably even have it fully replaced in
> the future.
I think
Hello,
On Thu 13 Jun 2024 at 12:04am +02, Joerg Jaspert wrote:
> Now, again: tag2upload/dgit is not in this category. Not even a little
> nor close to.
Indeed.
> And then something that didn't appear yet: Has anyone asked the Salsa
> admins if they even would like tag2upload? Tell you what,
Hi,
thanks to all for this GR. I like tag2upload in principle. The only
thing I'm a bit scared about is that it simplifies uploading something
that was never built before on the local machine. Sure, this can be
done with source-only uploads as well, but tag2upload makes it even
easier.
Maybe
Hello,
On Wed 12 Jun 2024 at 12:37pm +01, Luca Boccassi wrote:
> This is largely in the eye of the beholder as there's no strict
> definition that I am aware of, so one could or could not include
> these, but I do note that what you describe above is not really that
> different from Alioth -
* Marco d'Itri: " Re: [RFC] General Resolution to deploy tag2upload" (Wed, 12
Jun 2024 14:37:25 - (UTC)):
> deb...@kitterman.com wrote:
>
> >As I understand it, Debian was affected by the xz-utils hack, in part,
> >because some artifacts were inserted into an upstream tarball that were not
On 6/12/24 00:25, Sean Whitton wrote:
Hello everyone,
This is a draft GR. >
> [...]
Hi Sean,
Thanks for your work on this.
One thing I really dislike, is having a single gpg key to upoload them
all. I very much preferred the design that Didier explained during
Debconf Kosovo, where the
Hi,
On 6/13/24 06:00, Luca Boccassi wrote:
Yes, that's the argument - all Salsa features are bad and "bloat":
issues are bad, teams are bad, CIs are bad, merge requests are bad,
the only thing needed is to push to some git backend, everything
else is bad and unneeded.
The requirements for
73 matches
Mail list logo
