On 25.06.24 01:26, HW42 wrote:
But you are trusting the Developer system that signs the tag or source
package anyway. If compromised it can simply sign malicious code in both
cases.
It's not that easy.
Hiding compromised code in our tarballs is easy. Nobody will ever look
at them (ordinarily)
Hi,
On 6/25/24 09:38, Brian May wrote:
But like it or not mistakes can happen. e.g. somebody applies a security
update to the project. And uploads it to Debian. But forgets to do a git
push to salsa.
You can only call it "forgetting" to do a git push if you introduce a
policy that contributi
Russ Allbery writes:
> HW42 writes:
>> And, if yes: Why wouldn't they do the equivalent with the sources in
>> git (work on the less trusted system, transfer commits (git push/pull)
>> to the system with signing access and sign there, without review)?
> They will, I assume. But tag2upload requ
Russ Allbery writes:
> Misattribution of the source package
For a real life problem that I imagine tag2upload will solve:
It is reasonable common that git is the "authoritative source of truth"
for the current state of the project.
But like it or not mistakes can happen. e.g. somebody app
HW42 writes:
> Russ Allbery:
>> For the third purpose, I believe only weak intent information can be
>> derived from the uploader signature today. It is common practice in
>> Debian to verify the Git tree that one wants to upload, run a package
>> build step, and then blindly sign the resulting s
HW42 writes:
> Russ Allbery:
>> This attack is not equivalent to compromise of the uploader's OpenPGP
>> key, which neither upload architecture defends against. Many Debian
>> uploaders build source packages on less-trusted systems where they also
>> build and test binary packages, and then sign
Russ Allbery:
> [...]
> I worked on an update of my security review last night to take into
> account the additional concerns that people have raised and other
> feedback.
>
> [...]
>
> The source package signature can be used for three purposes:
>
> 1. Detect modifications to the source package
Russ Allbery:
> Below is the security review that I did of the tag2upload design.
> [...]
> The existing upload architecture requires trusting the host used by the
> uploader to build the source package. If that host is compromised, an
> attacker could inject malicious code into the source package,
Was the xy-utils compromise not happening until we became aware of it?
There could be packages in Debian compromised this way right now and we
wouldn't know unless we specifically looked for it. And even then we would
not have much to actually compare to in order to detect such problem. Which
devel
On Jun 24, 2024 7:03 PM, Matthias Urlichs wrote:
>
> On 24.06.24 17:33, Scott Kitterman wrote:
> > None of that changes the fact that it's what they signed.
> Well, that shouldn't prevent us from allowing them to sign something
> else instead. Like, a git tag.
> >Historically, the
I understand the theory. Are we aware of it happening?
Scott K
On June 24, 2024 7:42:25 PM UTC, Aigars Mahinovs wrote:
>It's pretty simple. Compromise the computer of one developer, the one they
>use for development. Have your code be in one of the tools being called
>during Debian source packa
It's pretty simple. Compromise the computer of one developer, the one they
use for development. Have your code be in one of the tools being called
during Debian source package build (you don't even need root, just writable
element in PATH). Now you can inject a malicious payload directly into the
t
Do you have any examples of problems that this would have avoided (xz-utils
isn't one - due to the way it's releases are done, it wouldn't be suitable for
tag2upload)?
Scott K
On June 24, 2024 6:36:59 PM UTC, Aigars Mahinovs wrote:
>Signing something that you did not write and something that y
Signing something that you did not write and something that you don't read
is a bad security practice that exposes you to various attacks.
Just because we have been doing this poor security practice for a long time
does not make it better. Now better methods are possible and we shouldn't
prevent t
This message from a while back was still in my queue to respond to, and
since I was updating my security review anyway, I wanted to think through
it a bit more. I think I understand what Sam is getting at.
Sam Hartman writes:
> Sorry I was assuming that the web ui and the git repository were st
On 24.06.24 17:33, Scott Kitterman wrote:
None of that changes the fact that it's what they signed.
Well, that shouldn't prevent us from allowing them to sign something
else instead. Like, a git tag.
Historically, the project has found that useful
Part of the reason for this usefulness is th
Aigars Mahinovs writes:
> On Sun, Jun 23, 2024, 19:17 Scott Kitterman wrote:
>> As an example, I think the fact that I can download any source package
>> in the archive and cryptographically verify who uploaded it and that
>> it's unmodified from what was uploaded is an important property of our
On June 24, 2024 2:48:49 PM UTC, Aigars Mahinovs wrote:
>On Sun, Jun 23, 2024, 19:17 Scott Kitterman wrote:
>
>> As an example, I think the fact that I can download any source package in
>> the
>> archive and cryptographically verify who uploaded it and that it's
>> unmodified
>> from what was
On Sun, Jun 23, 2024, 19:17 Scott Kitterman wrote:
> As an example, I think the fact that I can download any source package in
> the
> archive and cryptographically verify who uploaded it and that it's
> unmodified
> from what was uploaded is an important property of our current archive
> structu
On 23.06.24 21:13, Micha Lenk wrote:
Okay, but couldn't the existing git-based workflows get formalized and
standardized without changing the way how you upload to Debian?
Note the plural, which is a large part of the problem.
Yes they can, in fact most of them already are; that's the "dgit
Micha Lenk writes ("Re: Summary of the current state of the tag2upload
discussion"):
> Am 23.06.24 um 20:32 schrieb Ian Jackson:
> > Most people maintain their packages in git. Many upstreams regard git
> > as canonical, and publish tarballs not at all, or only as a
> > concession. [...]
>
> Ye
Ansgar, Joerg,
Discussion has died down without a resolution of our impasse, but Ian
sent a very long message, so perhaps you are working through it.
Could you let me know if you are still working on further responses, and
if so, roughly how long you think you need?
Thanks.
On Sat 22 Jun 2024 a
Hi,
On 6/24/24 10:19, Marco d'Itri wrote:
I think we have seen and still see with usrmerge how difficult and cumbersome
the resolution of an initially as simple presented project turned out. I
understand the answer of Scott directed in that way, at least this is a
reservation of mine.
For th
23 matches
Mail list logo
