Please review the draft for March's report

[Santiago Torres-Arias]

On Tue, Apr 06, 2021 at 05:02:58PM +0000, Daniel Shahaf wrote:
> Good morning Santiago,

Hi!

> > Do notice that verification is not part of the user story yet (i.e.,
> > anybody can claim to own any artifact).
> 
> So, if I understand correctly, sigstore doesn't prove to third parties
> that Alice had signed foo; rather, sigstore simply states "We have
> witnessed Alice sign foo".  Alice doesn't actually need to be involved
> for sigstore to be able to say that.  Thus, I think the technical
> details boil down to """

Well, yes in a sense sigstore allows you to get a key based on oidc
(similar to let's encrypt), or allows you to stick your usual signatures
in the log (i.e., the witnessing element you're mentioning). Let me try
to rephrase on the text below and see if I can help with that.

> 
> diff --git a/_reports/2021-03.md b/_reports/2021-03.md
> index 080f089..52dd630 100644
> --- a/_reports/2021-03.md
> +++ b/_reports/2021-03.md
> @@ -18,8 +18,6 @@ In our monthly reports, we try to outline the most important things that have ha
>  
>  [F-Droid](https://www.f-droid.org/) is a large repository of open source applications for the Google Android platform. This month, Felix C. Stegerman announced [*apksigcopier*](https://github.com/obfusk/apksigcopier), a new tool for copying signatures for `.apk` files from a signed `.apk` file to an unsigned one which is necessary in order to verify reproducibly of F-Droid components. Felix  filed an [Intent to Package (ITP)](https://wiki.debian.org/ITP) bug in Debian to include it in that distribution, too ([#986179](https://bugs.debian.org/986179)).
>  
> -On 9th March, the Linux Foundation announced the [*sigstore*](https://sigstore.dev/what_is_sigstore/) project which is intended to improve the security of the software supply chains through cryptographically signed transparency log techniques. According to the [their announcement](https://linuxfoundation.org/en/press-release/linux-foundation-announces-free-sigstore-signing-service-to-confirm-origin-and-authenticity-of-software/):
> -
> -> sigstore will empower software developers to securely sign software artifacts such as release files, container images and binaries. Signing materials are then stored in a tamper-proof public log. The service will be free to use for all developers and software providers, with the sigstore code and operation tooling developed by the sigstore community.
> +On 9th March, the Linux Foundation announced the [*sigstore*](https://sigstore.dev/what_is_sigstore/#what-is-sigstore) project, which is a centralized service that allows users to cryptographically sign and store signatures for release artifacts for developers who don't wish to manage their own PGP keypairs.
>  
>  [![]({{ "/images/reports/2021-03/openssf.png#right" | relative_url }})](https://openssf.org/)
> 
> """, but I'm sure you'll find this inaccurate, unfair, or worse.  

I made some minor edits, that I think may help with clarity. I wasn't
trying to be incredibly pedantic about the phrasing, but rather to be
upfront about sigstore not having a trust policy (yet). Sigstore is
actively working with communities (such as this one) to better identify
what policies make sense (e.g., to allow to represent and enforce a
build being reproducible).

> Given that you're involved the effort, and perhaps aware of plans to
> address this in the future, perhaps you could propose better text for
> the blog post?

Definitely, I should've engaged more with the early LF press-releases (I
try to stick to systems building, research and education). I supplied a
quote as a Purdue University professor, but that's as far as my
engagement was with the press push.

My earlier email is intended to help disambiguate. I agree that the
blogpost/announcement is quite content-free when read through with a
fine comb.

Cheers!
-Santiago
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20210406/8bc379f4/attachment.sig>