Please review the draft for March's report

[Daniel Shahaf]

Good morning Santiago,

Santiago Torres-Arias wrote on Tue, Apr 06, 2021 at 10:50:20 -0400:
> > I think mentioning sigstore is value. Reproducible builds let you verify that
> > a given build *is* generated from a given source; sigstore can let you
> > verify that you got the *correct* source or build.
> 
> I think mentioning sigstore is a good idea (Full disclosure, I'm
> involved in the effort), and I think it's somewhat of a natural
> consequence to the work that Benjamin Hof[1] and Morten Linderud[2]
> (both of them involved in this very community) started talking about.
> 
> However, I don't think that "sigstore can let you verify that you got
> the *correct* source or build" is a correct way to frame things. For
> that, you would need something like in-toto (so as to verify that the
> source used is the same, that the output is the same, and that a
> threshold of builders agree on the result of the operation).
> 
> Sigstore is useful in answering questions about artifact discovery
> (i.e., to provide a log of the existing artifacts), when they appeared
> and to remove equivocation about an artifact being published. It in fact
> provides a pluggable type backend (early on, it was only in-toto
> attestations) so that you can upload different types of attestations
> about a software artifact. This way, you can upload signatures for
> artifacts that are cross-ecosystems.  Ideally, you can achieve a more
> global notion about the state of the software supply chain this way.
> 
> 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 """

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 cryptographically signs 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.  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?

Cheers,

Daniel