> On Feb 1, 2023, at 6:48 PM, Orians, Jeremiah (DTMB)
> wrote:
>
>> Last I checked, CVE-2007-4559 is still not fixed; and surely not the only
>> unfixed (let alone currently unknown)
>> such vulnerability that may suddenly become a problem when you switch to a
>> scheme where you need to
>
Hi there, let me just share the latest status of reproducible Docker/OCI
container image builds with BuildKit: https://github.com/moby/buildkit
(OCI = "Open Container Initiative", not "Oracle Cloud Infrastructure")
BuildKit v0.11 was released in the last month with very preliminary support
for SOU
> Last I checked, CVE-2007-4559 is still not fixed; and surely not the only
> unfixed (let alone currently unknown)
> such vulnerability that may suddenly become a problem when you switch to a
> scheme where you need to
> unpack an archive before you can verify the authenticity of its contents.
[... some context elided since this is getting quite long ...]
* "David A. Wheeler" [2023-02-01 20:48]:
> > Unfortunately, you've left out the details of the archive format here,
> > when they are actually quite important.
> >
> > You now need to unpack an archive (e.g. a .zip or .tar) before yo
On Wed, Feb 01, 2023 at 12:53:24PM -0500, David A. Wheeler wrote:
> I recommend that the reproducible-builds website have a short article
> *specifically* recommending how signatures, OmniBOR data, & similar metadata
> should be shared.
[...]
> Is there agreement on adding such a page?
Yes, I'd s
> On Feb 1, 2023, at 13:40, FC Stegerman wrote:
>
> * Marc Prud'hommeaux [2023-02-01 18:12]:
>> I recently noticed a similar vulnerability in the W3C MiniApp
>> packaging draft [...]
>
> Interesting, thanks for the info!
>
>> But in the context of an Android app, where it sounds like it has
On Wed, Feb 01, 2023 at 02:48:15PM -0500, David A. Wheeler wrote:
>
>
> > On Feb 1, 2023, at 2:07 PM, FC Stegerman wrote:
> >
> > * "David A. Wheeler" [2023-02-01 17:20]:
> >>> Agreed. And I often wish Android had used detached signatures. Though
> >>> detached signatures would have made dis
> On Feb 1, 2023, at 2:07 PM, FC Stegerman wrote:
>
> * "David A. Wheeler" [2023-02-01 17:20]:
>>> Agreed. And I often wish Android had used detached signatures. Though
>>> detached signatures would have made distributing APKs more challenging:
>>> a single file is much more convenient for
* "David A. Wheeler" [2023-02-01 17:20]:
> > Agreed. And I often wish Android had used detached signatures. Though
> > detached signatures would have made distributing APKs more challenging:
> > a single file is much more convenient for end users.
>
> Sure, but the solution is trivial.
>
> Cre
* Marc Prud'hommeaux [2023-02-01 18:12]:
> I recently noticed a similar vulnerability in the W3C MiniApp
> packaging draft [...]
Interesting, thanks for the info!
> But in the context of an Android app, where it sounds like it has
> runtime access to the original .apk artifact and signing data, t
I recommend that the reproducible-builds website have a short article
*specifically* recommending how signatures, OmniBOR data, & similar metadata
should be shared.
In short, do *NOT* embed such data (especially signatures) in complex formats
like ELF or PE.
Instead, create an archive with the "
I recently noticed a similar vulnerability in the W3C MiniApp packaging draft,
whereby they embed signatures for the individual zip entries in the (legal)
padding between the final entry and the zip's central directory[1]. This seems
clever, but it means that only the individual entries, and n
>> Agreed. And I often wish Android had used detached signatures.
>> Though detached signatures would have made distributing APKs more
>> challenging:
>> a single file is much more convenient for end users.
> Sure, but the solution is trivial.
> Create something that you want signed ("item A").
> On Jan 31, 2023, at 8:59 PM, FC Stegerman wrote:
>
> Agreed. And I often wish Android had used detached signatures. Though
> detached signatures would have made distributing APKs more challenging:
> a single file is much more convenient for end users.
Sure, but the solution is trivial.
C
14 matches
Mail list logo
