Incorrect authenticity procedure in Readme

[freedom-foundation]

https://github.com/Kunzisoft/KeePassDX#verify-the-authenticity-of-the-downloaded-app-from-github

Oh and to comment on this while I made you @J-Jamet look at the verification.f-droid.org server. Notice what the verification server does, it actually cut's the signature certificates off then pastes them back on. Because this is demonstratably done checking for a good signature only as you have here https://github.com/Kunzisoft/KeePassDX#verify-the-authenticity-of-the-downloaded-app-from-github does not verify authenticity. All this seems to be doing is verifying the certificate which can have simply been pasted on as you see was done with the f-droid verification server process. In order to verify the authenticity of the app some tool would need to be used to verify signed data. This is essentially the same cryptography process which PGP and GPG use. Not check for any pasted on certificatr. You need to verify signed data with a trusted key.

[J-Jamet]

I'll say it again, if you don't want to use the application I generate locally and sign with my certificate because you don't trust me, you can use your own compiler that you can install on servers if you want. The procedure in the Readme ensures that the APKs generated and uploaded to the Github repository have been built and signed by my certificates.

If you want to use F-Droid's multiserver build and verification tools, you can, it's just another method.

I don't know what you mean by "the certificate which can have simply been pasted" and "not check for any pasted on certificatr", a certificate intrinsically works in the same way as an encryption system with public and private keys. I give the public keys that prove that I'm the one who built the applications, that's all.

In order to verify the authenticity of the app some tool would need to be used to verify signed data

Yes Keytool, it's in the terminal command. Then for each build, I make a hash of the generated APK so you can check the integrity of the file.

[freedom-foundation]

I'll say it again,

No. This is a separate issue which does not directly apply to Verifiable Rebuilds or My Private Trust Model. The issue here is APK Signatures.

[freedom-foundation]

I don't know what you mean by "the certificate which can have simply been pasted" and "not check for any pasted on certificatr",

What I mean is just what I say. The demonstration is all spelled out for you here https://f-droid.org/docs/Reproducible_Builds/#reproducible-signatures you have to read the page. What you will see is that it is quite possible to cut an embedded key out and simply paste it into an unsigned APK. Your keytool instructions only print the signature fingerprint which may have been simply slapped onto any APK. This is what I am telling you with the title that your process means nothing. You would have to take the next step and do the equivication of GPG "verify signed data".

[freedom-foundation]

a certificate intrinsically works in the same way as an encryption system with public and private keys. I give the public keys that prove that I'm the one who built the applications, that's all.

Yeah but you are not doing this. Nobody is taking the required step of using public key to verify signed data. You don't seem to be alone on this however wrong.

[freedom-foundation]

The summary here is that while it would be good to "verify the authenticity of the downloaded app from github" the steps that have been printed under this title DO NOT verify the app. A more apropos title would be "print the fingerprint of the key purported to have signed the APK" then never check to see if the APK was actually signed by any given key.

[J-Jamet]

What I mean is just what I say. The demonstration is all spelled out for you here https://f-droid.org/docs/Reproducible_Builds/#reproducible-signatures you have to read the page. What you will see is that it is quite possible to cut an embedded key out and simply paste it into an unsigned APK. Your keytool instructions only print the signature fingerprint which may have been simply slapped onto any APK. This is what I am telling you with the title that your process means nothing. You would have to take the next step and do the equivication of GPG "verify signed data".

I've read the article and what it says is that the signature is extracted and copied back into the unsigned APK which corresponds to the same sources of the first APK. If the two APKs are then identical, then the sources have not been modified. This doesn't mean you can extract the signature and paste it into any other APK to certify it.

Tools to do that : https://github.com/obfusk/apksigcopier https://developer.android.com/tools/apksigner

To check that the APK is well signed, use this type of command :

apksigner verify --verbose --print-certs KeePassDX-4.0.8-libre.apk

You will see "Verified using v2 scheme (APK Signature Scheme v2): true", I'll update the APK signature scheme which is still in v2 and the Readme.

Here, if you want to use the same Fdroid method with the APKs I deploy on github, you have to rebuild from source, extract my certificate and reimplement it in your built APK. (But you'll probably run into problems explained here : https://f-droid.org/docs/Reproducible_Builds/#potential-sources-of-unreproducible-builds)

[And please, write only one answer]

[freedom-foundation]

@J-Jamet You might call this a "whoopsie" player.

What I mean is just what I say. The demonstration is all spelled out for you here https://f-droid.org/docs/Reproducible_Builds/#reproducible-signatures you have to read the page. What you will see is that it is quite possible to cut an embedded key out and simply paste it into an unsigned APK. Your keytool instructions only print the signature fingerprint which may have been simply slapped onto any APK. This is what I am telling you with the title that your process means nothing. You would have to take the next step and do the equivication of GPG "verify signed data".

I've read the article and what it says is that the signature is extracted and copied back into the unsigned APK which corresponds to the same sources of the first APK.

Yes. "the certificate which can have simply been pasted"- pasted on any unsigned APK.

If the two APKs are then identical, then the sources have not been modified.

No. The article is not about the sources this is about the output.

This doesn't mean you can extract the signature and paste it into any other APK to certify it.

The article does not say this. You CAN cut a signature from an APK and paste it into any unsigned APK. Therefore as your README.md mis-instruct printing the checksum ( or "fingerprint" ) of the certificate means nothing. This is what you call a security documentation vulnerability wherin the documentation put's the user in a vulnerable position: misinformed and ignorant unable to learn because of a false-premise. The false-premise of thinking printing a checksum of any given certificate "verifies" and carryon without having verified the APK. If you must choose between calling this a ( question ) or a ( bug ) the latter is more apropos. While it is not a bug against the software it is your README.md contained in this repo which should instruct the proper use of the software. The flaw ( bug ) is everything under the title "verify the authenticity of the downloaded app from github". The steps that have been printed under this title DO NOT verify the app. I have provided an article which does demonstrate why these steps do not verify the APK and it does even go so far as to demonstrate that your signature may be pasted onto any APK. Printing the checksum of the embedded key does absolutely nothing to verify the APK. At most this attests it is your pubkey- nothing else. The article was given as a demonstration that yes a signature can be pasted to any APK. There is no assumption the user has ascertained the mathematical process contained in the cryptography sourcecode.

Tools to do that : https://github.com/obfusk/apksigcopier https://developer.android.com/tools/apksigner

To check that the APK is well signed, use this type of command :

A better way to word this is "To verify the APK". You should scope your English within the context of what is being spoken of. The terminology is "verify". You need to study Phil Zimmerman's PGP trust model to get the terminology right. It does not verify that it is "well signed" as you called it. PGP has a peer directed trust model where a specific signature may be called a "good signature". That is not what you are doing here you are "verifying" the APK has been signed by the embedded signature. The equivication in PGP is "verify signed data".

apksigner verify --verbose --print-certs KeePassDX-4.0.8-libre.apk

You will see "Verified using v2 scheme (APK Signature Scheme v2): true", I'll update the APK signature scheme which is still in v2 and the Readme.

When you do this it should fix the ( bug ).

Here, if you want to use the same Fdroid method with the APKs I deploy on github, you have to rebuild from source, extract my certificate and reimplement it in your built APK. (But you'll probably run into problems explained here : https://f-droid.org/docs/Reproducible_Builds/#potential-sources-of-unreproducible-builds)

Forewarning appreciated. I have written up a things to avoid checklist for us. I will be looking into making a branch of the app which is slimmed down.

[And please, write only one answer]

A single reply here. Try to stay focused.

[J-Jamet]

I understand better what you mean now, it's simply the KeyTool command to be replaced by ApkSigner. But it wasn't obvious for this ticket, you start by pointing out that F-Droid cuts certificates for its APK validation method and then you talk about PGP.

If you had simply said that the Keytool command doesn't check the APK, but only the certificate signature, which could be copied into any APK. That would have sufficed.

The section of the Readme that uses the command comes from an external Pull Request. And I thought it was good to add this simple check to find out which certificate is affixed to the APK, I didn't go any further, there was nothing before.

If the documentation is not suitable, one solution was also to Pull Request that updates the documentation directly. If I have to guess what users are thinking, I'm not done yet.

[freedom-foundation]

I understand better what you mean now, it's simply the KeyTool command to be replaced by ApkSigner. But it wasn't obvious for this ticket, you start by pointing out that F-Droid cuts certificates for its APK validation method and then you talk about PGP.

I mean nothing such: I do not endorse ApkSigner. I mean what I say. I pointed out a ( bug ) a documentation flaw. Yes I used a peer demonstration to prove the point that your documentation is meaningless. A signature CAN be cut from an APK and pasted to any other APK. Yes PGP uses asynchronous keys this cryptography model is necesarry to describe how to actually verify an APK ( bugfix ). I wouldn't be suprised if APK signing is simply a variation of GPG GPL.

If you had simply said that the Keytool command doesn't check the APK, but only the certificate signature, which could be copied into any APK. That would have sufficed.

I did say something to that effect.

The section of the Readme that uses the command comes from an external Pull Request. And I thought it was good to add this simple check to find out which certificate is affixed to the APK, I didn't go any further, there was nothing before.

You took a bad pull.

If the documentation is not suitable, one solution was also to Pull Request that updates the documentation directly. If I have to guess what users are thinking, I'm not done yet.

That link is a separate issue and has nothing to do with this, but shouldn't have to guess that is an idiom.

[freedom-foundation]

You show a lack of cryptography knowledge therefor it is a wonder why you are developer of this cryptography intensive app KeepassDX.

[J-Jamet]

Why not ApkSigner? What do you endorse then? It's an Android project, it's the right tool for me, the one I usually use and in the official doc. So please explain I can't guess what you're thinking.

I mean what I say.

You've said that several times. But the aim is to understand each other, just concise and point out what's technically wrong without interpreting it. I didn't understand the purpose of this issue, you put the link to the Readme and started talking about F-Droid.

I did say something to that effect.

You didn't even mention "Keytool" anywhere. I reread, indeed you indicated, my bad. I just didn't understand this issue.

You took a bad pull.

Indeed, I had to either change the title or change the command. I just didn't pay attention because it's a doc.

You show a lack of cryptography knowledge therefor it is a wonder why you are developer of this cryptography intensive app KeepassDX.

What is the purpose of this remark? How did you measure my level in cryptography with a few exchanges? Is it to support a documentation error in order to denigrate the knowledge and entire work carried out? It's to demotivate me? I'm doing this project in my spare time, so if there are any mistakes, I'll correct them, I learn and be done with it.

But above all, I expect kind and concise exchanges, you go off in different directions to explain simple things. If we can learn from each other, then that's beneficial, but let's keep it technical, not personal. Thank you.

[J-Jamet]

The Readme section has been deleted manually. I'll rewrite it when I have time.

[freedom-foundation]

Why not ApkSigner? What do you endorse then? It's an Android project, it's the right tool for me, the one I usually use and in the official doc. So please explain I can't guess what you're thinking.

Initially because I have not checked out the tool ApkSigner to know if it works. I do not endorse any of it. I do recommend studying Phil Zimmerman's PGP. Can and will you link the source for ApkSigner? Please do.

I mean what I say.

You've said that several times. But the aim is to understand each other, just concise and point out what's technically wrong without interpreting it. I didn't understand the purpose of this issue, you put the link to the Readme and started talking about F-Droid.

That is what I mean. There is no interpretation.

I did say something to that effect.

~You didn't even mention "Keytool" anywhere.~ I reread, indeed you indicated, my bad. I just didn't understand this issue.

You took a bad pull.

Inqdeed, I had to either change the title or change the command. I just didn't pay attention because it's a doc.

About not paying attention to docs. Yeah I notice this exclusion of the end-user in the development priority however the word application implies everything about it is intended for the user. How the user is to apply the software in use is a large part of the application in whole therefor documentation may be seen as a good half of the application. You could look at it like this: Docs are half the application.

You show a lack of cryptography knowledge therefor it is a wonder why you are developer of this cryptography intensive app KeepassDX.

What is the purpose of this remark? How did you measure my level in cryptography with a few exchanges? Is it to support a documentation error in order to denigrate the knowledge and entire work carried out? It's to demotivate me? I'm doing this project in my spare time, so if there are any mistakes, I'll correct them, I learn and be done with it.

The purpose is ambiguous- a simple statement of a truth. My measure is what I observed. This Doc error does bring into question the entire work, yes. Couldbe demotive; because the purpose is ambiguous: where you take it from here is up to you.

But above all, I expect kind and concise exchanges, you go off in different directions to explain simple things. If we can learn from each other, then that's beneficial, but let's keep it technical, not personal. Thank you.

I only go off in different directions because you take it there and to be frank this is a bother; might call it a communication ( bug ). While being concise may be a fair target, the complexities of software development such as many dependencies and assumptions about those dependencies often makes the rule of being concise infeasible. However my bugreport is fairly concise the problem is stated and with a supporting paper- so there should be no dispute. This should have been a quick open and fixed and closed bug.

[freedom-foundation]

The Readme section has been deleted manually. I'll rewrite it when I have time.

You can probably leave it at that: that is a quickfix. You're welcome.

[freedom-foundation]

I see the bug has been fixed.