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
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
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
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)
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=yes
>
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
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 view this r
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
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 introduce a
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
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
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
>
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
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
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
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
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.
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
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
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
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
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
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.
>
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:
+---
|
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
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
>
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
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
> "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
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
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
>>
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
>
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
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
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
> "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
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
>
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
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
39 matches
Mail list logo
