digikam.org doesn't list any signatures and/or cryptographic hashes to verify downloads. This is kinda crucial since the kde download site automatically redirects to mirrors, operated by third parties and more often than not using unencrypted protocols (http, ftp). So in this scenario I'd have to trust three and more parties, only one of which is digiKam/KDE: 1) digiKam 2) The operator of the mirror (I'm sure "klaus-uwe" running "mirror.klaus-uwe.me" is a nice guy, but maybe he is not). 3) Anybody in a MITM position, so my ISP, their ISP, internet exchanges, the NASA, the KGB, the Mossad, the BUND...err...BND, Al Gore (who invented the Internet), some guy calls Nils K. who keeps spying on me although he denies this, etc. At the very least *prominently* enough provide signatures and/or cryptographic hashes I can verify*. * (After some random clicking around I found that All Downloads/Metadata actually shows hashes)
>digikam.org doesn't list any signatures and/or cryptographic hashes to verify >downloads. Really ??? You talking about what exactly ? All files which can be downloaded from digiKam.org (and mirrors) are signed with MD5 sums... What else ? Gilles Caulier
First of all, MD5 is not a signature (nor really recommended as a cryptographic checksum). Then I see nothing on https://www.digikam.org/download/ that looks like a signature or hash, I had to dig a few levels deep into download.kde.org to find hashes.
The KDE files server used to share application bundles or tarball is not an application store. We provide MD5 sum to proff the no corrupted files to download. That all. The digikam.org do not host any files to download from client side. All is stored and mirrored by kde.org. That all. The MD5 sum is a properties of file available on web interface. If this workflow is not fine for you, ask to KDE admin. We (digiKam team) have no way to change that. We provide files to share to KDE admin and files are shared following KDE rules. Gilles Caulier
digikam.org is the authoritative source of downloads for a lot of people. As such it is YOUR obligation to provide at the very least hashes, even better signatures (e.g. gpg) and/or code-signed binaries (which would solve the issue of a compromised digikam.org server, too) >The digikam.org do not host any files to download from client side. >All is stored and mirrored by kde.org. That all. That's exactly the problem. When downloading digikam, it will not be downloaded from https://digikam.org/ (secured by TLS), but instead it will be downloaded from some KDE mirror (most likely over an unencrypted channel and therefore subject to man-in-the-middle attacks). The only way to verify the download is not tampered with or corrupted during transfer is some form of checksum/signature, which is not readily available from digikam.org. > We (digiKam team) have no way to change that. Yes, you do, by stating cryptographic hashes or signatures of known-good release files on https://www.digikam.org/download/ Just like about every other open source product does these days.
This report is for system admins from kde.org, not for digiKam team which delegate the job to publish files in download area. The KDE system admins can be contacted to phabricator.kde.org. There is no more bugzilla entries for system admin, since phabricator is used in parallel. The right url to register a new request to system admin is this one: https://phabricator.kde.org/maniphest/task/edit/form/2/ Of course you need an account in phabricator.kde.org Gilles Caulier
I re-open this file as i can see that official KDE tarballs are provided with .sig compressed text files including PGP signatures : https://download.kde.org/stable/applications/18.08.0/src/ Ben, how are computed this PGP data ? Which keys are used in this case ? This can be processed with sysadmin workflow while files are push to download area ? Or do we need to do it before the sysadmin workflow ? Thanks in advance Gilles Caulier
The packages you see signed for Applications, Plasma and Frameworks are signed by their respective Release Managers and then uploaded to download.kde.org by them. Sysadmin has no access to the GPG keys used to generate those signatures. In this case you'll need to setup GPG appropriately Gilles, and upload signatures as part of your releases. @RealDolos: Our systems provide SHA256 and SHA1 sums for all files hosted on both download.kde.org and files.kde.org. All you need to do is append .sha1 or .sha256 and our systems will serve the appropriate signature to you, directly, over HTTPS. This should provide a reasonably secure channel to verify the tarballs have not been tampered with by a mirror.
Thanks Ben, I will investigate Gilles Caulier
Again, the issue is not kde infrastructure, it's digikam.org Steps to reproduce --- 1. google digikam 2. go to digikam.org 3. Click download button 4. Click one of the download links (which says https://download.kde.org in the tip, so secure, right?!) 5. File Save dialog pops up, so save the file 6. Look around on the download page ( https://www.digikam.org/download/ ) for some way of verifying the download. Find none 7. Look at the download, see was actually retrieved from some http-only unsecured mirror (I only saw it by accident). 8. Look again at the download page ( https://www.digikam.org/download/ ) for some way of verifying the download. Still find none Options for 9. 9.1. YOLO, just install the NSA-MITMed executables. 9.2. Throw away the download and don't use digikam at all because the file could have been bugged by the FSB-MITM. 9.3. Click around a lot, spend 30 minutes and get frustrated tracking down where on the kde.org sites the actual signatures are, even tho digikam.org clearly isn't kde.org. But if you're well educated and knowledgeable like I am (the best user ever!), I somehow know digikam and kde are related. 9.4. Do not even notice the file was not securely transmitted and is now bugged by the Chinese-MITM (all tooltips and the URL bar said https all the time, RIGHT?!), so install the botnet. 9.5 Phew, I got it from an https enabled mirror! Everything is good now! https://downloads.notspying.dontbeevil.dgse.fr/ would never do anything bad! 10. uh, I actually installed it in 9., and now all my monies were transmitted to some Nigerian Prince (his words) who runs the mirror I was redirected to and and shipped a malware executable instead of the real deal to me. Expected: --- Do 1. to 5. 6. Look around on the download page ( https://www.digikam.org/download/ ), read the warning to verify the download, find the signatures or links to the signatures on that very site. 7. Verify and install digikam. 8. Enjoy the software (hopefully) >All you need to do is append .sha1 or .sha256 and our systems will serve the appropriate signature to you, directly, over HTTPS. This should provide a reasonably secure channel to verify the tarballs have not been tampered with by a mirror. Now I know that. However, eveybody else who googled and found digikam.org still does not.
I am looking into this right now and might have a solution to at least provide a link to a sha256 sum, as long as they get created and exist alongside the provided binaries. This will still require the packagers to create an sha256 sum when they create their binaries, and to upload them along with the binaries.
Our systems automatically generate both SHA-1 and SHA-256 hashes for all files we host, so you can rely on https://download.kde.org/..../file.sha256 and https://files.kde.org/..../file.sha256 always working (where file is the name of the file in any given case)
To Ben from Comment #7 Setup GPG keys is done on my computer, but where to upload the public keys ? What's the best practice ? A public server ? digikam.org ? Gilles
The public key should be uploaded to the PGP public key server network, as is standard practice for GPG keys. I'd suggest consulting distribution packager documentation for more detail about that. The signatures can then be uploaded beside the files.
I've added links to sha256 hashes for downloads (on staging, will merge soon). If/when you want to include PGP/GPG keys just let me know and I'll get them included as well. You can upload keys to a couple of common servers like: https://pgp.mit.edu/ https://sks-keyservers.net/
Generating PGP keys is done. The question is where to store the private key. This question is important because we share a the key to decrypt the signature to a 3rd party web service. We must be in confiance with this service. So my question is what the best practice from KDE projects to do that. I prefer to use a common service used by plenty open source projects instead to use one randomly. And i'm surprised to not see KDE project providing this kind of service. Ubuntu for ex provide this service for ex. I read plenty of documentation of to host PGP keys, but none convince me to use a specific one for open source project especially. Gilles Caulier
The private key shouldn't be stored anywhere other than your personal systems as the key in question doesn't belong to the project, but to you. If anyone else were to make a release of DigiKam, then they would use their own key to sign the releases. In regards to the Public Key, that should be uploaded to the public servers (which propagate keys amongst themselves so you don't have to pick one, it will get shared to them all in time)
Ok, the public PGP key is published on the network : https://pgp.mit.edu/pks/lookup?op=vindex&search=0x4A77747BC2386E50 Gilles Caulier
Git commit 57a10b6f44bf33950b0837ea151fb6a5172f5bdf by Gilles Caulier. Committed on 29/08/2018 at 19:18. Pushed by cgilles into branch 'master'. new option to compute GPG signatures for all bundles M +10 -0 project/bundles/appimage/04-build-appimage.sh M +3 -0 project/bundles/appimage/config.sh M +10 -0 project/bundles/macports/04-build-installer.sh M +3 -0 project/bundles/macports/config.sh M +10 -0 project/bundles/mxe/04-build-installer.sh M +3 -0 project/bundles/mxe/config.sh https://commits.kde.org/digikam/57a10b6f44bf33950b0837ea151fb6a5172f5bdf
Git commit e19356b5daf9b84864ce8203152dc2565dc1fa14 by Gilles Caulier. Committed on 29/08/2018 at 19:37. Pushed by cgilles into branch 'master'. sign tarball with PGP M +6 -0 bootstrap.tarball https://commits.kde.org/digikam/e19356b5daf9b84864ce8203152dc2565dc1fa14
RealDolos, I fixed all scripts to bundle digiKam at release time. Here you will found all bundles + PGP signatures + checksums. https://files.kde.org/digikam/ The source code tarball is not here because it just published only a release date. This folder is only to host intermediate release bundles for testing. But the rules are the same to compute the PGP signature for the tarball. Please check if all is fine for you. Gilles Caulier