Open freedom-foundation opened 2 months ago
Where were these assets built? and can you verify the builds can be reproduced having the same checksum for the rebuild?
Locally with my signature keys, which proves that I'm the one who built them and yes.
The last version veifiably rebuilt by f-droid was 4.0.5 with the next release failing rebuild verification.
I've just checked the F-Droid build, the latest one is version 4.0.8 and works without a hitch. If you don't trust me and trust F-Droid more, just get the F-Droid version and if you don't trust anyone, compile the application from source with your keys. https://f-droid.org/repo/com.kunzisoft.keepass.libre_131.log.gz
Sure. However, I welcome you to co-operate: Could make it easier to produce DDC verity builds because you already have a build system in place.
The last version veifiably rebuilt by f-droid was 4.0.5 with the next release failing rebuild verification.
I've just checked the F-Droid build, the latest one is version 4.0.8 and works without a hitch.
Again I say 4.0.5 is the last to verify. You may see for yourself on verification.f-droid.org. The following releases did not verify you will see a diffoscope there. Have you been able to verify those sources which did not verify for f-droid? Seems you do not yet grasp the verity to source process.
Okay, I understand better what you mean. I don't double-check the hash of the first built with another automatic server built.
Have you been able to verify those sources which did not verify for f-droid?
Which source are you referring to exactly? From what I can see of the 129 diffoscope, it seems that lambda references are changing and method call numbers are being inverted. Maybe the two servers don't have exactly the same compiler versions.
RE: " Have you been able to verify those sources which did not verify for f-droid? " I got your answer: NO. Which leaves me to stand to reason what you are claiming is verified rebuildable when you say:
and yes.
are you saying you build it twice on the same system?
Which source are you referring to exactly?
Each version after 4.0.5 has corresponding sourcecode which would be from you so you shouldn't have any confusion when I said "those sources". I am referring to the sources which have produced a diffoscope after 4.0.5 release.
Obviously a password manager is a critical app to have verity to source. I am pleased to see you looked at what may be causing a diffoscope can you tell me any more about why the diff is happening?
IMPORTANT: Until f-droid can get another verity to source garuntee I have trusted 4.0.5. Has 4.0.5 any known vulnerabilities that you are aware of?
Maybe the two servers don't have exactly the same compiler versions.
Shouldn't need exact same compiler for the compiler to have produced the product the sourcecode has told the compiler to produce.
This bug could now be closed with a no garuntee after 4.0.5 the app corresponds to the purported sourcecode. You would put (won't fix don't know how).
However, I will be pleased to continue the discussion with you.
Anybody building apps should get aquainted with DDC https://github.com/freedom-foundation/Countering_Trusting_Trust_through_Diverse_Double-Compiling the word diverse actualy means you would have differen't compilers. Shouldn't need exact same compiler for the compiler to have produced the product the sourcecode has told the compiler to produce.
We have to remain logical. If a compiler has upgraded, it must have optimized compiled code or corrected unexpected behavior, otherwise there would be no compiler upgrade. And even within the same version, the compiler may use different temporary variables, which wouldn't surprise me. As the SDK and NDK are compiled here, we need to check that two different machines building the same code produce the same hash. From what I've seen with the diffoscopes, it would seem not. This may be a parameter to be added, but it's worth looking into.
Something is sketchy about your GitHub page can you point it out?
Something is sketchy about your GitHub page can you point it out?
What do you mean by that?
Something is sketchy about your GitHub page can you point it out?
What do you mean by that?
You use your finger and point at the part of your GitHub that look's sketchy.
Can you explain why you are even checking the shasum of a rebuild? This would be enough if the compiler were a known verified and trusted compiler; without such at best the shasum would be lableing a "pick yer poison" gambit. What is your reasoning? Also if I separate the TOTP 2FA into another app it lessens the necessity to trust this KeepassDX app because a compromise of the database does not gain full access to the accounts; can you reccomend any separate TOTP app?
Because you asked me if it produced the same hash for a reconstruction. Quite simply. I'll say it again, but if you don't trust my build or f-droid's, do it yourself with your compiler. I recommend using two databases for TOTP, you can also search for a dedicated application yourself - there are plenty out there.
No, you already had the checksums before I asked therefor I ask what is YOUR reasoning for doing such.
Yeah I'll have to browse around for a TOTP app. Two databases can you calculate the most secure configuration? That would be interesting reason to see.
So because your app is the only which I have noted to use the argon2id encryption which may be necesarry on journaled filesystems I have opted to use two keepassdx apps but this is weighing all of the trust into YOU. This is why we need good competition it separates supply lines and such. the overall term is anti-trust. The more discussion the more likely somebody will be able to gain competency I had invited you to a countering trusting trust repo of mine however I have imported all of Master Wheeler's Key_materials for us at freedom-foundation/Fully_Countering_Trusting_Trust please join me for healthy discussion. You can pickup on my question about your reasons for shasum there. I look forward to it. :-)
No, you already had the checksums before I asked therefor I ask what is YOUR reasoning for doing such.
I'm hashing an APK after a build. If I redo the hash after another build on another machine and it's identical, I say yes.
Two databases can you calculate the most secure configuration?
It depends on many factors and contexts, so it's up to you to make up your own mind.
So because your app is the only which I have noted to use the argon2id encryption which may be necesarry on journaled filesystems I have opted to use two keepassdx apps but this is weighing all of the trust into YOU.
Once again, you don't have to trust me if you check the source code and compile it yourself.
The article on DDC is interesting, but you have to understand that I'm only the developer of the application. If you want several compilation sources for multiple comparisons and verifications, you need several different players who validate each work without trusting each other. This requires several dedicated infrastructures, which is possible but requires considerable resources. One solution would be to offer incentives to pay for these resources and validate the build and validation chains.
No, you already had the checksums before I asked therefor I ask what is YOUR reasoning for doing such.
I'm hashing an APK after a build. If I redo the hash after another build on another machine and it's identical, I say yes.
Didn't you say you are not using another build server or another machine? In what was sortof a gripe about f-droid doing this. Why don't you head on over to my repo I have invited you to and continue this discussion as it is not directly ontopic with the issue I have raised and closed. There is an on-point study of peer to peer exchange of checksums I will show you.
Two databases can you calculate the most secure configuration?
It depends on many factors and contexts, so it's up to you to make up your own mind.
A well informed decision or "educated guess" has prerequisit of some knowledge of the working mechanics thus the sourcecode; being the sourcecode author you would be the master in this domain the only to have that knowledge: the best to ask. Anyway this is why you find me here. Outside of an educated guess one may make up his own mind by a coinflip.
Once again, you don't have to trust me if you check the source code and compile it yourself.
Is this buildable from termux? Otherwise it may be a long drawn out process requiring an expensive computer lab.
The article on DDC is interesting,
Absolutely interesting.
you need several different players who validate each work without trusting each other.
@J-Jamet Hey player, with 255 contributors to KeePassDX do 'you' really have a lack of players? or do you suggest you and the 255 including competetive product author bpellin are all in cahoots? All 255 in trusting trust with one another?
One solution would be to offer incentives to pay for these resources and validate the build and validation chains.
hmm, yes. One is not sure if anybody is interested in War Bonds: Who might be? and indulgencia. What is the incentive for you and I?
Didn't you say you are not using another build server or another machine?
Indeed, I was just checking.
Why don't you head on over to my repo I have invited you to and continue this discussion as it is not directly ontopic with the issue I have raised and closed. There is an on-point study of peer to peer exchange of checksums I will show you.
Not much time, so I prefer to focus on technique.
Is this buildable from termux?
I don't know
@J-Jamet Hey player, with 255 contributors to KeePassDX do 'you' really have a lack of players? or do you suggest you and the 255 including competetive product author bpellin are all in cahoots? All 255 in trusting trust with one another?
hmm, yes. One is not sure if anybody is interested in War Bonds: Who might be? and indulgencia. What is the incentive for you and I?
What are you talking about? I'm just saying that multiple build servers doing replay for certificate validations isn't free and it needs to be synchronized and secured if it's managed by several players.
I'm closing the discussion, another thread may be opened if it's to discuss technical issues on build reproduction with F-Droid. If you still wish to reply, please make only ONE message.
When you close these discussions, because it is on your repo, do these (or can these) disappear to where I can't reference them?
I guess, I don't work for github.
For the purposes of this issue: Reproducible builds are a set of software development practices that create an independently-verifiable path from source to binary code. The keyword of mine was "verify". See title: Verify rebuild is reproducible.
@J-Jamet take a look at this repro_avoids.txt and see if it is any doable for you. I made a checklist as well but not sure how to post it. If you can get the code in order I can build a repro locally on my side.
How do you do To Study que? I have some TODOs Research and heavenly GITs in my repos.
Reproducible rebuild needed. I noticed an array of checksumming is done for release assets. Where were these assets built? and can you verify the builds can be reproduced having the same checksum for the rebuild?
The last version veifiably rebuilt by f-droid was 4.0.5 with the next release failing rebuild verification. The 4.0.5 asset here has a different checksum then f-droid if the sourcecode here is the same as the f-droid zip this may be because of a differing build system. Verifying that your project can build the same output twice (as f-droid has) should be a step forward.