Problem Description
I cannot verify that the release I download from Github was created by you.
Proposed Resolution
Use GPG to sign each release / provide a signed list of file hashes and / or a .sig file for each file released.
jonathancross
All 8 comments
Hello,
This shouldn't be on a wish list.
This is a extremely important point especially because of the nature of the software and the ability to edit the content on the GitHub Wiki. I was able to keep my Wiki modifications (faked the download links to some tweets) for more than one hour (probably would have been more if I didn't sent a tweet to one of the member of this repo and would had created an anonymous Github account named "Phil Brown" as GitHub does not show the username but only the name on each Wiki page, to see the username you need to go in the history which most people don't do).
I also would love to see the .pkg/.msi properly signed for each OS (in complement of the .sig / checksums for each release) and see the Wiki moved as a proper repository (e.g. OpenSC-Wiki): people who wants to contribute would need to do a PR and be approved by an administrator.
Regards,
pwnsdx
on 18 Aug 2017
The point of a wiki is "free to edit", thus I would be reluctant to close up the wiki for commiters only, even if it would make sense for a subset of pages.
The good part of Github Wiki is that it is git+markdown, thus converting it to other forms (like a documentation repository) would be easy. BUT the fact is that there is uneven distribution of quality, legacy, maybe-outdated, hard-to-verify-without-hardware parts of code and documentation about OpenSC and different cards, thus it would be a bit difficult to turn it into a solid "documentation repository", which would be possible for Apache or some other software-only project where information would be understood and setups repeatable and verifiable to almost anyone who invests some time. Access to hardware is key (pun intended) with OpenSC.
Another sad-but-true fact is that the developer community of smart card related projects has always been pretty small and is probably shrinking/ageing together with the technology. A lot of people are involved due to work relations and move on together with new professional projects. OpenSC is by no means a "developer group" (with regular online meetings and voting and politics and processes and whatnot) but a bunch of loosely connected hackers from different continents who have been coming and going throughout the years, with just a handful of names I remember from early 2000 still being around.
Keeping the threshold low for new blood is important, I believe that occasional bad actors who would abuse it can be avoided without tightening bolts, and that would definitely not keep out the dedicated malicious actors.
Maintaining integrity is important (open source and git are good starters), technical measures such as checksums (Git!) help here, so would reproducible builds (anyone cares to invest time, for macOs/Windows?). For every kind of signatures, one needs to think about the abused word "trust". Shall we thrive for a "green bar" in Github releases and a "padlock notice" in installers? Or some deeper point? Would it be a "verified signature" (with trust anchored to some kind of root, be it WoT or a CA), would the signature imply non-repudiation of the binary or just a "cryptographic timestamp over checksum"? Do self-signed, "TOFU" signatures (like random PGP keys uploaded to Github) count for valid signatures? Would you or someone else assume more essence from the signed code than the license implies (NO WARRANTY, AS-IS)? Why would any of the OpenSC developers be a good trust anchor for everyone in the world, you are free to get the code, verify it, built it, add your credentials and use your "trust position" to help those who depend on such trust anchors to get the code or binaries in a "trusted way" (think: Linux distributions are doing it).
That being said, I also like the security theatre and do produce software builds/distributions that are signed with either PGP (I have a bunch of counter-signatures!), Apple (99€/year) or Windows code signing from a random CA that happens to be in in Windows root program (also costs something per year).
For some parts it is a mandated gatekeeping (eg. for a normal user to be able to install something without gymnastics (Apple) or being scared away by warnings (Windows) or to be able to install certain type of components at all (think: Windows drivers)) and I consider it as such - necessary theatre to please platform vendors and for them to be able to delegate blame if necessary. At the same time I make it very clear that this is open source code you are getting and comes with no warranty per se, the fact that it is signed does not remove the need for due diligence and vigilance.
Conclusion: integrity is important, integrity of unverified information gives you exactly what you would expect (verified bad bits), signing things for fun or profit requires resources and processes to make sense (and that sense is not universal). If you really care you should anyway do your own analysis and verification, from source to binary, ignoring the suspicious falsehoods presented to you by random folks on the internet ;)
Please elaborate what kind of signatures do you want/need and why and how that could be achieved :)
martinpaljak
on 19 Aug 2017
I understand the problem from the user perspective and wished everything would be smooth and automagically on all possible platforms. However, we don't currently have the man power, infrastructure and the hardware to do a better release management.
At the moment, we are relying on Github's identity management, i.e. when downloading from https://github.com/OpenSC/OpenSC/releases, you can be sure that only these people are pushing commits or publishing releases.
frankmorgner
on 20 Aug 2017
@martinpaljak Personally, I'm just looking for GPG signatures on releases. If the keys were also used on at least some commits, that would convince me that "_the person writing code_" also "_created this release_". Would be much better if all devs at least signed each other's keys too.
I sign every commit using a Yubikey or Nitrokey. It's really not hard and makes sense considering your project :-)
jonathancross
on 23 Aug 2017
It makes sense for GPG which is supported natively by git, indeed. But unfortunately most smart cards are not GPG compatible.
Anyway, I get your point and like to even bring this further by using a platform specific signing. But, for the reasons given above this is currently not possible.
frankmorgner
on 24 Aug 2017
I can sign & timestamp with my code signing certificate some existing (Windows?) releases if you trust me ...
=> will avoid warning in MS installation, but you will have a big "verified by My Smart Logon"
vletoux
on 25 Aug 2017
What kind of resources would be required for OS-native signing? Is this something that someone could sponsor?
I'm running into application issues in OSX where the vendor is able to figure out some workarounds, but I (and the vendor) suspect that those workarounds (on loading unsigned libraries) will become more and more challenging as time goes on.
patcable
on 21 May 2019
Please begin signing, whether it's GPG or Authenticode for Windows binaries by purchasing a publicly trusted code signing certificate, something is better than nothing.
Staja
on 13 Jun 2020
Related issues
dengert
·
19Comments
michaelweiser
·
8Comments
alex-nitrokey
·
13Comments
mrlnc
·
10Comments
RaymiiOrg
·
4Comments
Most helpful comment
The point of a wiki is "free to edit", thus I would be reluctant to close up the wiki for commiters only, even if it would make sense for a subset of pages.
The good part of Github Wiki is that it is git+markdown, thus converting it to other forms (like a documentation repository) would be easy. BUT the fact is that there is uneven distribution of quality, legacy, maybe-outdated, hard-to-verify-without-hardware parts of code and documentation about OpenSC and different cards, thus it would be a bit difficult to turn it into a solid "documentation repository", which would be possible for Apache or some other software-only project where information would be understood and setups repeatable and verifiable to almost anyone who invests some time. Access to hardware is key (pun intended) with OpenSC.
Another sad-but-true fact is that the developer community of smart card related projects has always been pretty small and is probably shrinking/ageing together with the technology. A lot of people are involved due to work relations and move on together with new professional projects. OpenSC is by no means a "developer group" (with regular online meetings and voting and politics and processes and whatnot) but a bunch of loosely connected hackers from different continents who have been coming and going throughout the years, with just a handful of names I remember from early 2000 still being around.
Keeping the threshold low for new blood is important, I believe that occasional bad actors who would abuse it can be avoided without tightening bolts, and that would definitely not keep out the dedicated malicious actors.
Maintaining integrity is important (open source and git are good starters), technical measures such as checksums (Git!) help here, so would reproducible builds (anyone cares to invest time, for macOs/Windows?). For every kind of signatures, one needs to think about the abused word "trust". Shall we thrive for a "green bar" in Github releases and a "padlock notice" in installers? Or some deeper point? Would it be a "verified signature" (with trust anchored to some kind of root, be it WoT or a CA), would the signature imply non-repudiation of the binary or just a "cryptographic timestamp over checksum"? Do self-signed, "TOFU" signatures (like random PGP keys uploaded to Github) count for valid signatures? Would you or someone else assume more essence from the signed code than the license implies (NO WARRANTY, AS-IS)? Why would any of the OpenSC developers be a good trust anchor for everyone in the world, you are free to get the code, verify it, built it, add your credentials and use your "trust position" to help those who depend on such trust anchors to get the code or binaries in a "trusted way" (think: Linux distributions are doing it).
That being said, I also like the security theatre and do produce software builds/distributions that are signed with either PGP (I have a bunch of counter-signatures!), Apple (99€/year) or Windows code signing from a random CA that happens to be in in Windows root program (also costs something per year).
For some parts it is a mandated gatekeeping (eg. for a normal user to be able to install something without gymnastics (Apple) or being scared away by warnings (Windows) or to be able to install certain type of components at all (think: Windows drivers)) and I consider it as such - necessary theatre to please platform vendors and for them to be able to delegate blame if necessary. At the same time I make it very clear that this is open source code you are getting and comes with no warranty per se, the fact that it is signed does not remove the need for due diligence and vigilance.
Conclusion: integrity is important, integrity of unverified information gives you exactly what you would expect (verified bad bits), signing things for fun or profit requires resources and processes to make sense (and that sense is not universal). If you really care you should anyway do your own analysis and verification, from source to binary, ignoring the suspicious falsehoods presented to you by random folks on the internet ;)
Please elaborate what kind of signatures do you want/need and why and how that could be achieved :)