>
> Building a source package is a lot more opaque and gives the attacker a
> lot more room to hide. Adding malicious code to tar to inject something
> into source packages is a lot quieter
How many packages have a pubkey for the orig file?
Perhaps we should encourage upstreams to sign more?
I
Quoting Salvo Tomaselli (2024-06-26 09:25:37)
> >
> > Building a source package is a lot more opaque and gives the attacker a
> > lot more room to hide. Adding malicious code to tar to inject something
> > into source packages is a lot quieter
>
> How many packages have a pubkey for the orig fil
> I am sure that's also what you meant, Salvo, I just find it quite
> relevant to be explicit that it is the care that need a boost, not the
> amount of signatures.
Well if you manually check very carefully every line and then don't sign… it's
harder to discover it got modified.
--
Salvo Tomase
On 25.06.24 23:14, Salvo Tomaselli wrote:
I think that the very same people who never check what's in a tarball are very
unlikely to start checking diffs.
IMHO you're mistaken.
(a) checking the source package is not a one-liner. You need to untar to
someplace temporary, run a recursive diff (
Le mardi, 25 juin 2024, 19.14:53 h CEST Russ Allbery a écrit :
> tho...@goirand.fr writes:
> > Watch the Kosovo lightning talk where Didier shows what he did. It is a
> > proven concept.
>
> If this is the proof of concept where the *.dsc file is encoded in a Git
> tag (sorry, there have been seve
Le mardi, 25 juin 2024, 22.13:53 h CEST Philip Hands a écrit :
> Aigars Mahinovs writes:
> > Do you actually check that the contents of the source *package* (after all
> > operations done by dpkg-source and possibly other tools) actually match
> > what you were looking at before in your source wor
Quoting Salvo Tomaselli (2024-06-26 10:29:53)
> > I am sure that's also what you meant, Salvo, I just find it quite
> > relevant to be explicit that it is the care that need a boost, not the
> > amount of signatures.
>
> Well if you manually check very carefully every line and then don't sign…
>
Hi,
We basically have three cases:
1. upstream has an official .orig.tar.* file we can use
In my opinion, we'd want to use this because we don't need to explain
how it was generated, and any signature from upstream can be used to
verify that we are shipping exactly their release.
I'm aware
> "Matthias" == Matthias Urlichs writes:
Matthias> A reproducibility checker for t2u seems like child's play,
Matthias> compared to that effort. While no t2u checker currently
Matthias> exists, somebody might be motivated enough to write
Matthias> one. (Hint, hint …)
You don'
On 26.06.24 13:18, Simon Richter wrote:
3. upstream needs to be repacked for dfsg reasons
So far, I believe this has no good representation in git […]
IMHO this is a mostly-solved problem.
You can feed hashes of the offenders to "git filter-repo
--strip-blobs-with-ids ‹filename›". This opera
Hi folks,
answering to some "random" mail in this thread since I do not manage to
follow everything. My pragmatic thought when browsing my malbox is that
I'm honestly wondering how many source packages the contributors in this
thread could have created manually in the time that was used to write
Simon Richter writes:
> 1. upstream has an official .orig.tar.* file we can use
> In my opinion, we'd want to use this because we don't need to explain
> how it was generated, and any signature from upstream can be used to
> verify that we are shipping exactly their release.
> I'm aware that th
Simon Richter writes ("tag2upload, reproducible .orig and dfsg repacks"):
> For 1. and 2., what I'd like to kind of see as part of the interface to
> a tag2upload service is a way to explicitly specify what kind of .orig
> archive should be constructed,
This is already there.
Firstly, everythin
Hi,
On 6/27/24 00:41, Russ Allbery wrote:
The second case seems fine with tag2upload? Particularly if upstream
signs the Git tag. Instead of pointing to a possibly signed release
tarball, the tag2upload tag points to a signed upstream Git tag. We get
basically the same properties and avoid d
Ian Jackson writes ("Re: tag2upload, reproducible .orig and dfsg repacks"):
...
> Secondsly, there is only currently one supported way to generate an
> orig: git-deborig aka git-archive.
An implication, which I should atate explicitly, is that if you want
something else (eg, to be sure use unmodif
Hi,
On 6/27/24 01:16, Ian Jackson wrote:
Secondsly, there is only currently one supported way to generate an
orig: git-deborig aka git-archive. So the protocol in this area is
fairly simple, and the possible extension to support other orig
generation modes is not described in the document.
S
Simon Richter writes:
> On 6/27/24 00:41, Russ Allbery wrote:
>> The second case seems fine with tag2upload? Particularly if upstream
>> signs the Git tag. Instead of pointing to a possibly signed release
>> tarball, the tag2upload tag points to a signed upstream Git tag. We
>> get basically t
Matthias Urlichs writes:
> IMHO this is a mostly-solved problem.
>
> You can feed hashes of the offenders to "git filter-repo
> --strip-blobs-with-ids ‹filename›". This operation is idempotent and
> deterministic.
>
> If we add these hashes to a file, let's say d/source/dfsg-filtered, we
> can
Hello Andreas,
On Wed 26 Jun 2024 at 04:17pm +02, Andreas Tille wrote:
> Is there any chance that we could bring the involved parties in one
> (virtual) room and discuss the thing directly? I'd love to serve as
> moderator in this room (with my DPL hat on).
Thanks for the idea, but we don't thi
Hi Matthias,
Am Wed, Jun 26, 2024 at 03:25:34PM +0200 schrieb Matthias Urlichs:
> You can feed hashes of the offenders to "git filter-repo
> --strip-blobs-with-ids ‹filename›". This operation is idempotent and
> deterministic.
>
> If we add these hashes to a file, let's say d/source/dfsg-filtered
20 matches
Mail list logo
