Re: git & Debian packaging sprint report

Hello, On Tue 23 Jul 2019 at 08:13PM +02, Ansgar Burchardt wrote: > There are also other useful properties the current implementation has: > for example the archive contains the artifact that was signed. This can > be checked at a later time unlike a Git tag on salsa.d.o that may or may > not ex

Re: git & Debian packaging sprint report

Russ Allbery writes: > Scott Kitterman writes: >> Except that we have different requirements than git. Git isn't looking >> for security properties from SHA-1, so it's highly likely it'll meet >> their accident avoidance requirements long after it's no longer >> appropriate for security related a

Re: git & Debian packaging sprint report

On Sun, 21 Jul 2019, Ian Jackson wrote: > IME as a sponsor I get (AFAICT) no mails as a result of my sponsorship > signatures so I think there are few automatic processes. That's actualy not true, dak is sending mails to the person who signs the upload when it has to send mails like NEW notificati

Re: git & Debian packaging sprint report

Ian Jackson writes: > Ie I think you would consider this a blocker for you to use it as a > sponsor. Do you consider this a blocker for deployment at all ? No, it's just a regular bug (in something), at least to me. -- Russ Allbery (r...@debian.org)

Re: git & Debian packaging sprint report

Russ Allbery writes ("Re: git & Debian packaging sprint report"): > What I probably should have said from the start is that the place where > this information shows up that I personally care about is at: > > https://qa.debian.org/developer.php?login=rra&co

Re: git & Debian packaging sprint report

Ian Jackson writes: > Russ Allbery writes ("Re: git & Debian packaging sprint report"): >> Ian Jackson writes: >>> I think in general those places are probably mistakes. But I'm not >>> aware of all of them. One way to look at this is that from t

Re: git & Debian packaging sprint report

Russ Allbery writes ("Re: git & Debian packaging sprint report"): > Ian Jackson writes: > > I think in general those places are probably mistakes. But I'm not > > aware of all of them. One way to look at this is that from the > > archive's point of v

Re: git & Debian packaging sprint report

Ian Jackson writes: > Russ Allbery writes ("Re: git & Debian packaging sprint report"): >> If so, I think that security model is roughly equivalent to the >> automatic signing of binary packages by buildds, so probably doesn't >> introduce a new vulnerab

Re: git & Debian packaging sprint report

Hi. Not replying to things others have dealt with, but... Russ Allbery writes ("Re: git & Debian packaging sprint report"): > If so, I think that security model is roughly equivalent to the automatic > signing of binary packages by buildds, so probably doesn't introd

Re: git & Debian packaging sprint report

On July 16, 2019 3:37:04 PM UTC, Russ Allbery wrote: >Scott Kitterman writes: > >> Except that we have different requirements than git. Git isn't >looking >> for security properties from SHA-1, so it's highly likely it'll meet >> their accident avoidance requirements long after it's no longer

Re: git & Debian packaging sprint report

Hello, On Tue 16 Jul 2019 at 10:45AM +02, Ansgar Burchardt wrote: > A "source package" generally consists of: > - a set of upstream artifacts (currently one or more tarballs, >signatures); can be the empty set for native packages > - Debian-specific artifacts > - the .dsc artifact (generat

Re: git & Debian packaging sprint report

Hello, On Tue 16 Jul 2019 at 08:37AM -07, Russ Allbery wrote: > The consensus among all of us was that if you have an opportunity to pick > something other than SHA-1 when designing a new protocol, you should. But > if it's not simple to pick a different hash, SHA-1 preimage resistance is > reas

Re: git & Debian packaging sprint report

Scott Kitterman writes: > Except that we have different requirements than git. Git isn't looking > for security properties from SHA-1, so it's highly likely it'll meet > their accident avoidance requirements long after it's no longer > appropriate for security related assertions. > I don't thin

Re: git & Debian packaging sprint report

Hi Sean, On 15.07.19 19:02, Sean Whitton wrote: > On Mon 15 Jul 2019 at 01:16PM +02, Michael Kesper wrote: > >> Nonetheless it seems to me you are moving from trusting local signing >> to trusting upload by salsa, thereby making salsa more attractive for >> attackers. > > I don't follow -- the g

Re: git & Debian packaging sprint report

On Tue, 2019-07-16 at 08:29 +0100, Sean Whitton wrote: > We also rely on git for security elsewhere. For example, dak is > deployed by ftpmasters pushing a signed git tag to salsa; a cronjob on > ftpmaster then deploys that code. That's relying on SHA-1 in pretty > much the same way as tag2upload

Re: git & Debian packaging sprint report

Hello, On Mon 15 Jul 2019 at 12:47PM -07, Russ Allbery wrote: > I'm dubious that we really care that much about a preimage attack on > SHA-1, [...] Someone suggested on IRC that such an attack on tag2upload is even less likely to be possible because each preimage has to be something which dpkg-s

Re: git & Debian packaging sprint report

On 15.07.19 22:50, Russ Allbery wrote: > At some point, Git itself will switch away from SHA-1, and we > can then obviously follow. According to [0]: - "Git v2.13.0 and later subsequently moved to a hardened SHA-1 implementation by default, which isn't vulnerable to the SHAttered attack. Thu

Re: git & Debian packaging sprint report

On July 15, 2019 8:50:48 PM UTC, Russ Allbery wrote: >Ansgar Burchardt writes: > >> SHA-1 isn't going to get stronger in the future. The TLS world has >> already moved on, OpenPGP is still in the slow process to move on, >> Release/Packages stopped using it[1], there is no reason to continue

Re: git & Debian packaging sprint report

On Mon, 2019-07-15 at 20:54 +0200, Ansgar Burchardt wrote: > Russ Allbery writes: > > If so, I think that security model is roughly equivalent to the automatic > > signing of binary packages by buildds, so probably doesn't introduce a new > > vulnerability, > > It doesn't rely on strong cryptograp

Re: git & Debian packaging sprint report

Russ Allbery writes: > Ansgar Burchardt writes: >> The client tool could possibly also just create the .dsc and .changes, >> except for hashes of the compressed files, and the web service just >> recreate the tarball and compress them. > > I think experience with pristine-tar indicates that recrea

Re: git & Debian packaging sprint report

Ansgar Burchardt writes: > SHA-1 isn't going to get stronger in the future. The TLS world has > already moved on, OpenPGP is still in the slow process to move on, > Release/Packages stopped using it[1], there is no reason to continue > using it. Well, the reason to continue using it is that Git

Re: git & Debian packaging sprint report

Russ Allbery writes: > Ansgar Burchardt writes: >> Russ Allbery writes: >>> If so, I think that security model is roughly equivalent to the >>> automatic signing of binary packages by buildds, so probably doesn't >>> introduce a new vulnerability, > >> It doesn't rely on strong cryptographic hashes

Re: git & Debian packaging sprint report

Ansgar Burchardt writes: > Russ Allbery writes: >> If so, I think that security model is roughly equivalent to the >> automatic signing of binary packages by buildds, so probably doesn't >> introduce a new vulnerability, > It doesn't rely on strong cryptographic hashes to guarantee integrity. >

Re: git & Debian packaging sprint report

Russ Allbery writes: > If so, I think that security model is roughly equivalent to the automatic > signing of binary packages by buildds, so probably doesn't introduce a new > vulnerability, It doesn't rely on strong cryptographic hashes to guarantee integrity. To quote Wikipedia: +--- | Revision

Re: git & Debian packaging sprint report

Hello, On Mon 15 Jul 2019 at 10:22AM -07, Russ Allbery wrote: > Just to make sure I fully understand the model, is the idea that this > system will verify the signature on the Git tag, construct a source > package from the signed archive, and then sign the resulting source > package with some int

Re: git & Debian packaging sprint report

Sean Whitton writes: > The current plan is for this machine to be firewalled such that it talks > only to salsa. For exactly the sort of reasons you describe, you won't > be able to use this with arbitrary git hosts. > The only untrusted input is the git tags before their signature has been > v

Re: git & Debian packaging sprint report

Hello Michael, On Mon 15 Jul 2019 at 01:16PM +02, Michael Kesper wrote: > Nonetheless it seems to me you are moving from trusting local signing > to trusting upload by salsa, thereby making salsa more attractive for > attackers. I don't follow -- the git tag is PGP-signed, locally, by the upload

Re: git & Debian packaging sprint report

Hi Sean, hi all, On 12.07.19 09:00, Sean Whitton wrote: > On Fri 12 Jul 2019 at 04:30am +00, Scott Kitterman wrote: > >> Has there been any analysis of the security implications of this >> proposed service? > > Nothing formal, though of course we were thinking about it while we were > working on

Re: git & Debian packaging sprint report

> "Sean" == Sean Whitton writes: Sean> If the BoF or e-mail discussion comes up with requirements Sean> which are impossible for our solution to satisfy, then we Sean> misjudged what to spend our time on at the sprint. Ian and I Sean> have been working on this stuff for long

Re: git & Debian packaging sprint report

Hello, On Sun 14 Jul 2019 at 09:48AM +02, Ansgar wrote: > What is the DebConf BOF then for? It says it is "a requirements > collecting BOF for that [git push] discussion"? To my mind, the BoF and the work at the sprint are two efforts to improve things that are running in parallel. I think we

Re: git & Debian packaging sprint report

Sean Whitton writes: > On Fri 12 Jul 2019 at 02:06PM +02, Ansgar wrote: >> Depends on a lot of things. As far as I understand this work is in a >> very early stage and a first brainstorming session on what problem this >> is intended to solve, why one should consider doing it, and possible >> requ

Re: git & Debian packaging sprint report

Hello, On Fri 12 Jul 2019 at 02:06PM +02, Ansgar Burchardt wrote: > Depends on a lot of things. As far as I understand this work is in a > very early stage and a first brainstorming session on what problem this > is intended to solve, why one should consider doing it, and possible > requirements

Re: git & Debian packaging sprint report

On Thu, 2019-07-11 at 17:58 -0300, Antonio Terceiro wrote: > > We designed and implemented a system to make it possible for DDs to > > upload new versions of packages by simply pushing a specially > > formatted git tag to salsa. [...] > If the uploads will be done by a service, this means that all

Re: git & Debian packaging sprint report

Hello Scott, On Fri 12 Jul 2019 at 04:30am +00, Scott Kitterman wrote: > Has there been any analysis of the security implications of this > proposed service? Nothing formal, though of course we were thinking about it while we were working on it. > If I am understanding the description correctly

Re: git & Debian packaging sprint report

On July 10, 2019 8:10:40 AM UTC, Sean Whitton wrote: >Hello, > >Over the weekend, Ian Jackson and I met in Cambridge, U.K. to work on >the design and implementation of tools and processes relating to git & >Debian packaging. > >Main achievement > > >We designed and implemented a

Re: git & Debian packaging sprint report

> "Andrej" == Andrej Shadura writes: Andrej> Hi, Andrej> On Wed, 10 Jul 2019 at 10:10, Sean Whitton wrote: >> Over the weekend, Ian Jackson and I met in Cambridge, U.K. to >> work on the design and implementation of tools and processes >> relating to git & Debian packagi

Re: git & Debian packaging sprint report

Hi, Thanks for the report. On Wed, Jul 10, 2019 at 09:10:40AM +0100, Sean Whitton wrote: > Hello, > > Over the weekend, Ian Jackson and I met in Cambridge, U.K. to work on > the design and implementation of tools and processes relating to git & > Debian packaging. > > Main achievement > ---

Re: git & Debian packaging sprint report

On Wed, 10 Jul 2019 09:10:40 +0100, Sean Whitton wrote: > Main achievement > > > We designed and implemented a system to make it possible for DDs to > upload new versions of packages by simply pushing a specially formatted > git tag to salsa. > > Please see this blog post to lea

git & Debian packaging sprint report

Hello, Over the weekend, Ian Jackson and I met in Cambridge, U.K. to work on the design and implementation of tools and processes relating to git & Debian packaging. Main achievement We designed and implemented a system to make it possible for DDs to upload new versions of packa