Re: Please review the draft for March's report
Holger Levsen wrote: > I also like the final order of the entries, though when I skimmed > through https://reproducible-builds.org/reports/2024-03/ I wondered > whether we should add a table of contents to the top of each post? > > What do y'all think? I used to always add one one, but haven't for a while. Still, the bumper amount of news in this month's report month does seem to ask for one... Added and pushed. Best wishes, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o
Re: Please review the draft for March's report
Dear Chris et al, On Thu, Apr 11, 2024 at 07:52:39PM +0100, Chris Lamb wrote: > > Please review the draft for March's Reproducible Builds report: > This has now been published — thanks to all who contributed. great, thank you and everyone involved indeed! I also like the final order of the entries, though when I skimmed through https://reproducible-builds.org/reports/2024-03/ I wondered whether we should add a table of contents to the top of each post? What do y'all think? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Manchmal kommt der Wind von Lee. (Konny) signature.asc Description: PGP signature
Re: Please review the draft for March's report
Chris Lamb wrote: > Please review the draft for March's Reproducible Builds report: This has now been published — thanks to all who contributed. If possible, please share the following link: https://reproducible-builds.org/reports/2024-03/ .. and also consider retweeting: https://twitter.com/ReproBuilds/status/1778496263027093713 Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o
Re: Please review the draft for March's report
On 4/10/24 7:12 PM, Chris Lamb wrote: Thank you for all the feedback so far. Unless someone makes these changes to the draft themselves, I will attend to this (and all the other critiques here and on Salsa) before publishing. Thank you! I noticed I submitted the backseat-signed tool in early April, so it makes sense it's not being mentioned in the report for March. Sorry for the confusion on my end. cheers, kpcyrd
Re: Please review the draft for March's report
Holger Levsen wrote: > On Wed, Apr 10, 2024 at 10:02:56AM -0400, David A. Wheeler via rb-general > wrote: >> I agree, this one is HUGE news. There's been a lot of awesome work related >> to reproducible builds, but "minimal container userland is a 100% >> reproducible build in a real-world widely-used distro" is a big step forward >> and should be widely announced. > > agreed. > > I also think the news about Vagrant helping Debian to confirm the xz related > builds have been fine, deserves a bigger headline. Thank you for all the feedback so far. Unless someone makes these changes to the draft themselves, I will attend to this (and all the other critiques here and on Salsa) before publishing. Best wishes, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o
Re: Please review the draft for March's report
On Wed, Apr 10, 2024 at 10:02:56AM -0400, David A. Wheeler via rb-general wrote: > I agree, this one is HUGE news. There's been a lot of awesome work related to > reproducible builds, but "minimal container userland is a 100% reproducible > build in a real-world widely-used distro" is a big step forward and should be > widely announced. agreed. I also think the news about Vagrant helping Debian to confirm the xz related builds have been fine, deserves a bigger headline. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ You cannot ban abortion. You can only ban safe abortions. signature.asc Description: PGP signature
Re: Please review the draft for March's report
> On Apr 10, 2024, at 7:42 AM, kpcyrd wrote: > > On 4/10/24 12:58 PM, Chris Lamb wrote: >> https://reproducible-builds.org/reports/2024-03/?draft > > > Reproducible builds developer kpcyrd reported that that the Arch Linux > > "minimal container userland" is now 100% reproducible after work by > > developers dvzv and Foxboron on the one remaining package. The post, which > > kpcyrd suffixed with the question "now what?", continues on to outline some > > potential next steps, including validating whether the container image > > itself could be reproduced bit-for-bit. The post generated a significant > > number of replies. > > Thanks for the kind words :) maybe it should be listed higher though, in its > own section, as "major accomplishment within the community"? I agree, this one is HUGE news. There's been a lot of awesome work related to reproducible builds, but "minimal container userland is a 100% reproducible build in a real-world widely-used distro" is a big step forward and should be widely announced. Like press release level. I routinely hear "reproducible builds are impractical". Yes, in some cases they're hard, but clearly there are cases where it's practical. --- David A. Wheeler
Re: Please review the draft for March's report
On 4/10/24 12:58 PM, Chris Lamb wrote: https://reproducible-builds.org/reports/2024-03/?draft > Reproducible builds developer kpcyrd reported that that the Arch Linux "minimal container userland" is now 100% reproducible after work by developers dvzv and Foxboron on the one remaining package. The post, which kpcyrd suffixed with the question "now what?", continues on to outline some potential next steps, including validating whether the container image itself could be reproduced bit-for-bit. The post generated a significant number of replies. Thanks for the kind words :) maybe it should be listed higher though, in its own section, as "major accomplishment within the community"? It's also missing both the backseat-signed tool and the discussion in it's thread that highlights the idea of "maybe we should put unmodified git snapshots into .orig.tar.xz instead of allowing undocumented pre-processing", for the security properties this would have. Unfortunately the repo of the project is currently difficult to clone, I've put 60MB of test data into git LFS, but Github only grants 1GB of traffic on free tier, allowing about 16 clones. The files can currently not be downloaded because I'd need to buy data packs. I also didn't have any time to continue the email thread, however I think I have made all my points sufficiently clear, for the people reading the thread in the future. There's currently a similar discussion on hacker news: https://news.ycombinator.com/item?id=39988269 Thanks!
Please review the draft for March's report
Hi all, Sorry for the delay in getting this out — it was, quite genuinely, a bumper amount of things that needed condensing, rewriting and generally getting into readable shape. Anyway, if folks would be so kind as to review the draft for last months report here: https://reproducible-builds.org/reports/2024-03/?draft … or, via the Git repository itself: https://salsa.debian.org/reproducible-builds/reproducible-website/blob/master/_reports/2024-03.md I intend to publish it no earlier than: $ date -d 'Thu, 11 Apr 2024 17:30:00 +0100' https://time.is/compare/1730_11_Apr_2024_in_BST § As ever, please feel free and commit/push to drafts directly without the overhead of sending patches or merge requests. You should make your changes to the "_reports/2024-03.md" file in the "reproducible-website" repository: $ git clone https://salsa.debian.org/reproducible-builds/reproducible-website $ cd reproducible-website $ sensible-editor _reports/2024-03.md I am happy to reword and/or rework additions prior to publishing. If you currently do not have access to the above repository, you can request access by following the instructions at: https://reproducible-builds.org/contribute/salsa/ Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o
Re: Please review the draft for March's report
Chris Lamb wrote: > Please review the draft for March's Reproducible Builds report: This has now been published — thanks to all who contributed. If possible, please share the following link: https://reproducible-builds.org/reports/2023-03/ .. and also consider retweeting: https://twitter.com/ReproBuilds/status/1644283929598337024 Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o
Please review the draft for March's report
Hi all, Please review the draft for March's Reproducible Builds report: https://reproducible-builds.org/reports/2023-03/?draft ⦠or, via the Git repository itself: https://salsa.debian.org/reproducible-builds/reproducible-website/blob/master/_reports/2023-03.md I intend to publish it no earlier than: $ date -d 'Thu, 06 Apr 2023 14:15:00 +0100' https://time.is/compare/1415_06_Apr_2023_in_BST § Please feel free and commit/push to drafts directly without the overhead of sending patches or merge requests. You should make your changes to the "_reports/2023-03.md" file in the "reproducible-website" repository: $ git clone https://salsa.debian.org/reproducible-builds/reproducible-website $ cd reproducible-website $ sensible-editor _reports/2023-03.md I am happy to reword and/or rework additions prior to publishing. If you currently do not have access to the above repository, you can request access by following the instructions at: https://reproducible-builds.org/contribute/salsa/ Regards, -- o ⬠⬠Chris Lamb o o reproducible-builds.org ð ⬠⬠o
Re: Please review the draft for March's report
Chris Lamb wrote: > Please review the draft for March's Reproducible Builds report: This has now been published — thanks to all who contributed. If possible, please share the following link: https://reproducible-builds.org/reports/2022-03/ .. and also consider retweeting: https://twitter.com/ReproBuilds/status/1512343602600550400 Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o
Please review the draft for March's report
Hi all, Please review the draft for March's Reproducible Builds report: https://reproducible-builds.org/reports/2022-03/?draft … or, via the Git repository itself: https://salsa.debian.org/reproducible-builds/reproducible-website/blob/master/_reports/2022-03.md I plan to publish it no earlier than: $ date -d 'Thu, 07 Apr 2022 17:00:00 +0100' https://time.is/compare/1700_07_Apr_2022_in_BST § Please feel free and commit/push to drafts without the overhead of sending patches or merge requests. You should make your changes to the "_reports/2022-03.md" file in the "reproducible-website" repository: $ git clone https://salsa.debian.org/reproducible-builds/reproducible-website $ cd reproducible-website $ sensible-editor _reports/2022-03.md I am happy to reword and/or rework additions prior to publishing. If you currently do not have access to the above repository, you can request access by following the instructions at: https://reproducible-builds.org/contribute/salsa/ Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o
Re: Please review the draft for March's report
Santiago Torres-Arias wrote on Tue, 06 Apr 2021 23:25 +00:00: > > Thanks! > > > > Where are those edits? I don't see them in reproducible-website.git or in > > your reply. > > Oh, I just pushed, my bad (I wanted to double check it rendered properly > locally and I went down a rabbit hole of fixing my gen environment...). > Let me know if this helps... Much better, thanks!
Re: Please review the draft for March's report
Chris Lamb wrote: > Please review the draft for March's Reproducible Builds report: This has now been published; many thanks to all who contributed. Please share the following URL: https://reproducible-builds.org/reports/2021-03/ And, if you are into that kind of thing, please consider retweeting: https://twitter.com/ReproBuilds/status/1379833931076407307 Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o
Re: Please review the draft for March's report
John, > Could someone please review my request for access? I sent my request a > month or so ago and would like to push typo fixes. My Salsa username is > jscott. Done! (For some reason salsa had stopped (?) notifying me that there were folks waiting.) Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o
Re: Please review the draft for March's report
On Mon, 2021-04-05 at 05:03 -0400, Chris Lamb wrote: > Please feel free and commit/push to drafts without the overhead of > sending patches or merge requests. > If you currently do not have access to the above repository, you can > request access by following the instructions at: > https://reproducible-builds.org/contribute/salsa/ Could someone please review my request for access? I sent my request a month or so ago and would like to push typo fixes. My Salsa username is jscott. signature.asc Description: This is a digitally signed message part
Re: Please review the draft for March's report
> Thanks! > > Where are those edits? I don't see them in reproducible-website.git or in > your reply. Oh, I just pushed, my bad (I wanted to double check it rendered properly locally and I went down a rabbit hole of fixing my gen environment...). Let me know if this helps... > > > 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. > > By "blog post" I actually intended to refer to r-b's monthly report, > since that one is due to be published tomorrow, but clarifying > sigstore's docs is of course also a good thing ☺ Oh, well, yeah... :) Cheers! -Santiago > > Cheers, > > Daniel signature.asc Description: PGP signature
Re: Please review the draft for March's report
Santiago Torres-Arias wrote on Tue, 06 Apr 2021 18:17 +00:00: > On Tue, Apr 06, 2021 at 05:02:58PM +, Daniel Shahaf wrote: > > > 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 > > ⋮ > > I made some minor edits, that I think may help with clarity. Thanks! Where are those edits? I don't see them in reproducible-website.git or in your reply. > 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. By "blog post" I actually intended to refer to r-b's monthly report, since that one is due to be published tomorrow, but clarifying sigstore's docs is of course also a good thing ☺ Cheers, Daniel
Re: Please review the draft for March's report
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
Re: Please review the draft for March's report
> On Apr 6, 2021, at 10:50 AM, Santiago Torres-Arias > wrote: > >> 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... > 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. I was trying to be “simple and one sentence”, which is necessarily imperfect. How about this as the 1-sentence summary?: “sigstore is designed to enable simpler cryptographic signing & signature verification”? --- David A. Wheeler
Re: Please review the draft for March's report
> 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). Cheers! -Santiago [1] https://arxiv.org/abs/1711.07278 [2] https://bora.uib.no/bora-xmlui/handle/1956/20411 > > --- David A. Wheeler > signature.asc Description: PGP signature
Re: Please review the draft for March's report
On Tue, 2021-04-06 at 10:39 -0400, David A. Wheeler wrote: > Press releases are not the best way to learn technical details :-). > > I suggest adding a link to more details e.g.: > > See https://sigstore.dev/what_is_sigstore/“>”What is sigstore" > for more details. > > 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. An interesting aside but Yocto Project sidesteps this issue by encoding the checksums of the source tarballs in it's recipes for software. Whilst that doesn't guarantee it is the correct source, it means that you're all using the same source and given the breadth of use of the project, you'd assume differences would be noticed and can certainly be audited. You'd be amazed how often we find projects that rebuild their release tarballs :/ Cheers, Richard
Re: Please review the draft for March's report
Press releases are not the best way to learn technical details :-). I suggest adding a link to more details e.g.: See https://sigstore.dev/what_is_sigstore/“>”What is sigstore" for more details. 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. --- David A. Wheeler
Re: Please review the draft for March's report
Daniel Shahaf wrote: > It's not our business to fix their press release, of course, but if we > link to something, we should ensure _our_ readers will be able to tell > what we link to and why it's significant. If their press release doesn't > explain that, then we could explain those bits ourselves, or link to > a more technical write-up [...] The Linux Foundation's press release is indeed rather content-free, even after we factor in that they have a different target audience in mind. If you have an alternative phrasing (or links to a more-technical write-up), please feel free to go ahead and commit that; I'm not wedded to the current text, and would prefer that these reports were less of a solo effort. Another solution you may wish to explore is truncating or otherwise shortened this entry — that would have the effect of deprioritising it, thus making the lack of hard/technical detail less of a problem when considered in context. Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o
Re: Please review the draft for March's report
On 06/04/2021 02.24, Daniel Shahaf wrote: > I don't understand from that post what's so significant about sigstore, > even after having followed the link to upstream's press release. I think, the problem that it tries to address is that most (90%?) of upstreams publish just tarballs/zipfiles without a cryptographic signature. E.g. [1] So as a packager, I download the file and have no way to verify that I got what the author meant to publish. Now, if you have a third party that also downloads the file and publishes a signature over what it got, you at least have another data point that helps you verify that your local wifi or a rogue mirror did not mitm your transfer or that at least everyone gets the same version (you could call it "reproducible downloads"). If it ever happens that such a 3rd party signing key leaked, you do not want years of signatures to become worthless => this is why they make keys short-lived - similar to how you can make syslogs tamper-proof. [1] https://ftp.gnu.org/gnu/autoconf/ https://avahi.org/download/ https://download.gnome.org/sources/audiofile/0.3/ http://mirror.synyx.de/apache/httpd/mod_fcgid/
Re: Please review the draft for March's report
Chris Lamb wrote on Mon, 05 Apr 2021 09:03 +00:00: > Please review the draft for March's Reproducible Builds report: > > https://reproducible-builds.org/reports/2021-03/?draft I don't understand from that post what's so significant about sigstore, even after having followed the link to upstream's press release. The key technical points of upstream's PR seem to be: > > Signing materials are then stored in a tamper-proof public log > > Very few open source projects cryptographically sign software > > release artifacts > > sigstore seeks to solve […] by utilization of short lived > > ephemeral keys with a trust root leveraged from an open and > > auditable public transparency logs. but none of that says what sigstore _actually does_, what attacks it aims to thwart, why it's new/significant… It's not our business to fix their press release, of course, but if we link to something, we should ensure _our_ readers will be able to tell what we link to and why it's significant. If their press release doesn't explain that, then we could explain those bits ourselves, or link to a more technical write-up (cf. https://m.xkcd.com/1301/), etc.. HTH, Daniel
Please review the draft for March's report
Hi all, Please review the draft for March's Reproducible Builds report: https://reproducible-builds.org/reports/2021-03/?draft ⦠or, via the Git repository itself: https://salsa.debian.org/reproducible-builds/reproducible-website/blob/master/_reports/2021-03.md I intend to publish it no earlier than: $ date -d 'Wed, 07 Apr 2021 16:00:00 +0100' https://time.is/compare/1600_07_Apr_2021_in_BST § Please feel free and commit/push to drafts without the overhead of sending patches or merge requests. You should make your changes to the "_reports/2021-03.md" file in the "reproducible-website" repository: $ git clone https://salsa.debian.org/reproducible-builds/reproducible-website $ cd reproducible-website $ sensible-editor _reports/2021-03.md I am happy to reword and/or rework additions prior to publishing. If you currently do not have access to the above repository, you can request access by following the instructions at: https://reproducible-builds.org/contribute/salsa/ Regards, -- o ⬠⬠Chris Lamb o o reproducible-builds.org ð ⬠⬠o
Re: Please review the draft for March's report
Chris Lamb wrote: > Please review the draft for March's Reproducible Builds report: This has now been published; many thanks to all who contributed. Please share the following URL: https://reproducible-builds.org/reports/2020-03/ Alternatively, if you are into that kind of thing, please consider retweeting: https://twitter.com/ReproBuilds/status/1247457901637140480 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Re: Please review the draft for March's report
Hi Chris, On Sat, Apr 04, 2020 at 02:06:03PM +0100, Chris Lamb wrote: > Please review the draft for March's Reproducible Builds report: > https://reproducible-builds.org/reports/2020-03/?draft looks good to me, thanks! -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Please review the draft for March's report
Hi all, Please review the draft for March's Reproducible Builds report: https://reproducible-builds.org/reports/2020-03/?draft … or, via the Git repository itself: https://salsa.debian.org/reproducible-builds/reproducible-website/blob/master/_reports/2020-03.md I intend to publish it no earlier than: $ date -d 'Tue, 07 Apr 2020 10:30:00 +0100' https://time.is/compare/1030_07_Apr_2020_in_BST § Please feel free and commit/push to drafts without the overhead of sending patches or merge requests. You should make your changes to the "_reports/2020-03.md" file in the "reproducible-website" repository: $ git clone https://salsa.debian.org/reproducible-builds/reproducible-website $ cd reproducible-website $ sensible-editor _reports/2020-03.md I am happy to reword and/or rework additions prior to publishing. If you currently do not have access to the above repository, you can request access by following the instructions at: https://reproducible-builds.org/contribute/salsa/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
