Unavailable releases/branches for reproducible builds

[scumjr]

We are happy to answer your questions about the code or discuss technical ideas.

Please complete the following checklist (by adding [x]):

• [x] I have searched open and closed issues for duplicates
• [x] This isn't a feature request
• [x] This is not a report about my app not working as expected

---

Related issues: #251, #129, #75

Hello,

After some trial and error, I used to successfully build proton-mail and proton-accounts web clients where the resulting files match the one in production on https://mail.proton.me and https://account.proton.me. I especially rely on the /assets/version.json files to retrieve build parameters and git info, however it doesn't work anymore.

At the time of writing, proton-accounts version.json is:

{
  "version": "5.0.63.0",
  "commit": "b3c54c5672aeaa370ca63eee18e920ee9ffcbe19",
  "branch": "proton-account@5.0.63.0",
  "date": "Thu, 26 Oct 2023 21:57:40 GMT",
  "mode": "sso"
}

However, there are:

• no release proton-account@5.0.63.0
• no commit b3c54c5672aeaa370ca63eee18e920ee9ffcbe19
• no branch proton-account@5.0.63.0

I encounter the same issue for proton-mail@5.0.30.8. In consequence, I fail at making Proton WebClients build reproducibly now.

Is there any reason why the public source code lags behind production releases? Issue #129 is related and marked as completed, but @vladimiry suggestions are still relevant IMHO.

For the context, I developed a (private) extension similar to Meta Code Verify for Proton, however it's useless without reproducible builds.

Thanks!

[vladimiry]

Can confirm the issue. Practice of not publishing sources of deployed version is back. So the source publishing process doesn't seem to be automated. I hope @mmso or someone on the team could shed some light on the issue.

[vladimiry]

ping

[vladimiry]

Hi @bartbutler, it's been 3+ weeks since the project code/tags updates stopped to happen, but proton.me keeps getting regular updates. Can you or someone shed some light on the issue?

[bartbutler]

Sorry, it'll return soon, there's a product reason for the delay.

[GlytchMeister]

This seems to be a practice that runs counter to the ethos of open source code. Not being able to view the code you are encouraging people to install isn't what I'd call "open." What is the reason for refusing to publish what should be open code?

Additionally, the official Proton account on reddit has been promising to publish the source code for Proton Calendar since at least 2022 from what I was able to see.

[TheDcoder]

Please provide the up to date sources and required metadata so that we can locally build ProtonMail for use in projects like ElectronMail.

[TimmyBoi155]

Please develop openly. Proton has made too many mistakes not in good faith, being open source is the last and final thing you have left.

[bartbutler]

We try to, sometimes the sync is disabled in order to not leak new features and undermine the announcements, but engineering always pushes to make these pauses as short as possible.

[bartbutler]

And while we have certainly made mistakes, none are done in bad faith.

[GlytchMeister]

We try to, sometimes the sync is disabled in order to not leak new features and undermine the announcements, but engineering always pushes to make these pauses as short as possible.

Really.

It's been at least two years since the proton reddit account promised to open-source the calendar.

That's not short.

[GlytchMeister]

And while we have certainly made mistakes, none are done in bad faith.

It is the users who are the judge of that.

Walk the walk, or quit talking the talk.

I know proton won't. I'm taking my money and going to Tuta.

[bartbutler]

True, iOS calendar is a black mark, that's mostly a resourcing thing with the team but agreed that it needs to be done. It has nothing to do with this repository though.

Regarding the decisions you are taking issue with, without any elaboration on what you are referring to I can't comment much, but I've likely had a front row seat for several of them and I can say that those I have been involved in weren't made in bad faith. You may not agree with the outcome or prioritization, I may not have agreed with the outcome or prioritization. But at the end of the day those decisions, right or wrong, were made with the goal o furthering the overall mission in some way and not in any sort of bad faith.

[vladimiry]

Thanks for sharing some more info on the issue.

sometimes the sync is disabled in order to not leak new features and undermine the announcements

This explains the delay (as the monorepo project nature sets the limitation), but not removing existing “tags” and stopping publishing new ones. So now it's impossible to get the same code slice that was deployed at proton.me at some point.

PS, I can see that "tags" publishing practice is got back now, and published tags are quite fresh. But the commit hash at https://mail.proton.me/assets/version.json and the respective published tag's hash are different:

So it introduces confusion. Before mid-April, tag's hashes used to be the same as on the proton.me's "version.json", but now it's not.

[bartbutler]

Hmm, I'll ask someone to look at that and get back to you.

[bartbutler]

OK, I'm told that this is due to adding a tool to filter out things like internal CI configurations, so you should not expect them to match going forward but you can trust the release tags in terms of the code.

[vladimiry]

Thanks for helping to sort this out, things seems to getting back to rails.

[bartbutler]

You're welcome, sorry for the hassle.