Towards a new release 0.18.0

[frankmorgner]

I think it's time to prepare and publish the next major release, @OpenSC/core, @OpenSC/maintainers.

I've created https://github.com/OpenSC/OpenSC/projects/4 with the open tasks I'd still like to see resolved for the release (Please extend the list if you're missing something).

Though I'd like to create a release candidate in about two weeks, I'm currently clueless on how to resolve #1226, which is somewhat of a blocker for a new release. I'm not sure if the problem is caused by OpenSC, my setup or my cards; some more independent input would be nice...

Below you'll find a draft for an update of the NEWS file:

---

General Improvements

• PKCS#15
  • fixed parsing ECC parameters from TokenInfo (New CardOS 5.3 not working #1134)
  • Added PKCS#15 emulator for DIN 66291 profile
  • Cope with empty serial number in TokenInfo
• Build Environment
  • Treat compiler warnings as errors (use --disable-strict to avoid)
  • MacOS
    • optionally use CTK in package builder
    • fixed detection of OpenPACE package
    • macOS High Sierra: fixed dmg creation
    • fixed DNIe UI compatibility
• Windows: Use Dedicated md/pkcs11 installation folders instead of installing to System32/SysWOW64
• fixed (possible) memory leaks for PIV, JPKI, PKCS#11, Minidriver
• fixed many issues reported via compiler warnings, coverity scan and clang's static analyzer
• beautify printed ASN.1 data, add support for ASN.1 time types
• SimpleTLV: Skip correctly two bytes after reading 2b size (Skip correctly two bytes after reading 2b size #1231)
• added support for keep_alive commands for cards with multiple applets to be enabled via opensc.conf
• added support for bash completion for arguments that expect filenames
• added keyword old for selecting card_drivers via opensc.conf
• improved documentation manuals for OpenSC tools
• use leave as default for disconnect_action for PC/SC readers

PKCS#11

• Make OpenSC PKCS#11 Vendor Defined attributes, mechanisms etc unique

Minidriver

• added CNS ATR (Italian CNS registry entries missing (Windows) #1153)
• Add multiple PINs support to minidriver
• protect MD entry points with CriticalSection

Tokend

• Configuration value for not propagating certificates that require user authentication (ignore_private_certificate)

CryptoTokenKit

• Added support for PIN pad
• fixed codesigning of opensc tools
• Added complete support for system integration with https://github.com/frankmorgner/OpenSCToken

OpenSC Tools

• cardos-tool
  • List human-readable version for CardOS 5.3
• pkcs11-tool
  • fixed overwriting digestinfo + hash for RSA-PKCS Signature
  • Enable support for RSA-PSS signatures in pkcs11-tool
  • Add support for RSA-OAEP
  • Fixed RFE: make EC_POINT_NO_ASN1_OCTET_STRING a runtime option in pkcs11-tool #1286
  • Add missing pkcs11-tool options to man page
  • allow mechanism to be specified in hexadecimal
  • fixed default module path on Windows to use opensc-pkcs11.dll
• pkcs11-spy
  • Add support for RSA-OAEP
  • Add support for RSA-PSS
• pkcs15init
  • Fix rutokenS FCP parsing (pkcs15init: Fix rutokenS FCP parsing #1259)
• egk-tool
  • Read data from German Health Care Card (Elektronische Gesundheitskarte, eGK)
• opensc-asn1
  • Parse ASN.1 from files
• opensc-tool/opensc-explorer
  • Allow extended APDUs

Authentic

• Correctly handle APDUs with more than 256 bytes ([AuthentIC v3] Correctly handle APDUs with more than 256 bytes #1205)

Coolkey

• Copy labels from certificate objects to the keys

Common Access Card

• Fixed infinite reading of certificate
• Added support for Alt token card

GoID

• added PIN commands for GoID 1.0

MyEID

• support for RAW RSA signature for 2048 bit keys

IAS/ECC

• Support for new MinInt agent card

PIV

• Get cardholder name from the first certificate if token label not specified
• implemented keep alive command (PIV detection of AID using Discovery Object before doing select AID - Partial Fix #1243 #1256)
• fixed signature creation with CKA_ALWAYS_AUTHENTICATE (i.e. PKCS#11 C_Login(CKU_CONTEXT_SPECIFIC))

CardOS

• fixed card name for CardOS 5
• added ATR "3b:d2:18:00:81:31:fe:58:c9:02:17"
• Try forcing max_send_size for PSO:DEC

DNIe

• DNIe: card also supports 1920 bits (DNIe: card also supports 1920 bits #1247)

GIDS

• Fix GIDS admin authentication

epass 3000

• Add ECC support
• Fix ePass2003 EC not supported #1073
• Fix feitian epass2003 is not working with opensc 0.17.0 on Fedora 26 #1115
• Fix buffer underrun in decipher
• Fix Improve code and fix sign bugs #1306

Starcos

• added serial number for 3.4
• fixed setting key reference for 3.4
• added support for PIN status queries for 3.4

EstEID

• ECDSA/ECDH token support
• Fix crash when certificate read failed (Crash in OpenSC with Estonian smart card devices #1176)
• Cleanup expired EstEID card ATR-s
• Fix reading EstEID certificates with T=0 (Fix reading EstEID certificates with T=0 #1193)

OpenPGP

• Added support for PIN logout and status
• factory reset is possible if LCS is supported
• Added support for OpenPGP card V3
• fixed selecting Applet
• implemented keep alive command
• Retrieve OpenPGP applet version from OpenPGP applet on YubiKey token (Retrieve OpenPGP applet version from OpenPGP applet on YubiKey token #1262)

German ID card

• fixed recognition of newer cards

SC-HSM

• Don't block generic contactless ATR
• changed default labels of GoID

Starcos

• Added Support for Starcos 3.4 and 3.5

MioCOS

• disabled by default, use card_drivers = old; to enable; driver will be removed soon.

BlueZ PKCS#15 applet

• disabled by default, use card_drivers = old; to enable; driver will be removed soon.

[Jakuje]

pkcs11-spy has also support for the RSA-PSS signature parameters, which is missing from your list.

[frankmorgner]

thanks, I've added this to the list.

[metsma]

EstEID ECDSA and ECDH, or just ECC

[frankmorgner]

updated to the most recent merges

[dpward]

There are some open pull requests with straightforward bug fixes (for example, #1319, #1325, etc.). Can these and similar pull requests please be evaluated before preparing a final release, which I understand happens about once a year?

[williamcroberts]

Does this release include the libp11 engine support for random?
Dumb question. I see this is only for things under OpenSC/OpenSC. I misread this as just OpenSC as in org level. Sorry for the noise.

[frankmorgner]

#1319 is not ready, see my comment here. #1325 needs testing. The changes are small enough to be integrated, if the requested changes/comments get done quickly.

[dengert]

I suggested the fix should be in pkcs15-sec.c #1319 to catch the problem for all cards.

The card in question is from ZeitControl. Anyone using their developer kit can write an applet and
end up with the same problem. This time it was an OpenPGP applet. What other applets could they write which would have the same problem?

If someone feels #1319 is not the place for the fix, submit a different PR. I have no way to test it.

The fix is not trivial when added to card-openpgp.c. The openpgp_compute_signature does not have direct access to the RSA modlen, as pkcs15-sec.c does not pass it in the senv and card-openpgp.c does save it in card->drvr_data. The driver has relied on the card returning the correct length of a signature.

[leio]

I would like to point out that Estonian ID cards are not usable at all with released versions of OpenSC since October or so, and every distribution needs to grab patches to correct this issue for a million potential users. Some distribution maintainers don't want to do that and prefer if OpenSC had it in a released version. I can imagine similar issues for other smartcards or use cases collected over the many months. Doing only one release per year is very problematic for that. Please simply release more often... Please seriously consider fixing the release process to not happen only once a year. If they happened more often, it wouldn't be such a huge issue in punting things to a later release and delaying a release for months, forcing the latest version to still have the countless other bugs and miss the new features for many more months than necessary.

[frankmorgner]

This is a community project. If you want change to happen, then engage and do what you think is needed! If there are problems that are not yet solved, please open a ticket. If you think some Estonian organization is obliged to fix things, please talk to them; we're happy to take their (or your) contribution.

[leio]

I have no access to make and upload releases more often, which is all that's needed here. Your suggestion to engage is a non-starter. I did open a ticket to ask for a release (#1216); this was closed in November 2017 with a pointer to the 0.18 release progress board. It is now April 2018 with no release having happened still, and released versions are still broken. The relevant Estonian organizations fixed all this about 5 months ago, but there is no OpenSC release that actually contains the fixes. Actually get the improvements this community is making out to its users! Effectively it is still broken, and only because releases happen only once a year.
See e.g. https://en.wikipedia.org/wiki/Release_early,_release_often

Currently we are waiting for a release that fixes hundreds of issues over 0.17.0 for months now due to waiting on 2-3 issues someone deemed nice to fix for the release, probably all of which are an issue with 0.17.0 as well.

It seems the 0.18 progress board is mostly clean now, so I hope it finally happens now, but please seriously consider doing more periodic releases going forward to avoid such problems. This can be very frustrating to your active contributors as well, if they have to wait 6+ months to actually get their code out to users...

[LudovicRousseau]

@leio do you volunteer to maintain OpenSC and perform the release process?

[leio]

No, I just want to be able to do internet banking without custom local downstream packages of my own after waiting for 5 months, as my opensc downstream maintainer prefers a release, not picking a patchset and hoping all is fine. And I didn't push for the patchset because the release progress board only had a couple things back then and a release seemed imminent. But now 4 months later, still nothing and still waiting. My actual useful volunteering to package esteid stuff in Gentoo (as opposed to having it available only in the rough equivalent of PPAs in a broken form due to no working OpenSC) is also blocked on OpenSC fixes getting into a release. Very frustrating.
Just take note of this, consider with adjusting processes in the future and lets move on. Comments like "Do you volunteer to do this" to chase away valid concerns aren't leading anywhere, other than more frustration. You know very well that a random person with probably only a few smartcard reader hardware not involved with things much at all can't take over maintenance, it's just a way to deflect (and get even more responses on the topic with direct questions).
Just see what can be done better in the future. As an outsider I would suggest releasing more often, and doing bugfix releases as necessary, instead of blocking a major release for 5 months due to 2-3 bugs, which could be released into that bugfix release once they are ready. But I don't know what sort of validation and whatnot you have in the processes now, and if they are worth blocking the release of many other bug fixes that are delayed and unavailable in a release because of that.

[mouse07410]

@leio do you have the necessary patches for OpenSC to make it work with Estonian ID? If so - where can I get those fixes from? Also, do you happen to know if Latvian eID is the same as Estonian - i.e., if the fixes for EstID would enable Latvian eID as well?

When you say "release" - do you mean providing compiled binaries? Or a version tag in Github? Or...?

In general I'd agree that we should release more often...

[metsma]

Patches are already in master
EstEID

• ECDSA/ECDH token support
• Fix crash when certificate read failed (Crash in OpenSC with Estonian smart card devices #1176)
• Cleanup expired EstEID card ATR-s
• Fix reading EstEID certificates with T=0 (Fix reading EstEID certificates with T=0 #1193)

[mouse07410]

@metsma I'm sorry, but what/where is EstEID master? And do you happen to know if Latvia and Estonia have the same eID standard (i.e., whether the code for EstEID should work with Latvian tokens)?

[leio]

@mouse07410 I mean https://github.com/OpenSC/OpenSC/releases of course. Anyhow, a rc1 is out by now, so hopefully not much longer to wait for this case. Concerns remain about the frequency, but at least I and my fellow distribution users can do internet banking once 0.18 is released finally; until the next case of needed fixes or feature additions. I don't know anything about Latvian eID. The EstEID stuff was for ECDSA/ECDH token support, which was necessary after ROCA incident (different tokens or whatnot used that weren't vulnerable to ROCA but the issued cards supported after OpenSC and other updates) - https://en.wikipedia.org/wiki/Estonian_ID_card#Weak_key_vulnerability - the necessary things for getting that to work again have been in OpenSC since November, but still not in a released version - which is what distributions package for Linux users (some have decided to include the necessary patches by themselves out of necessity, but not my distro, which is waiting for 0.18). I hadn't read anything from the media about Latvian cards being subject to ROCA too.

I'll conclude my involvement here on this ticket. There's been enough food for thought given for the future, and it looks like 0.18 is happening soon now anyways with rc1 already out, solving my months long wait hopefully soon.

[dengert]

Please consider #1334 for 0.18.0

[martinpaljak]

@mouse07410 While Estonia and Latvia share a border, there is no relation (in terms of code compatibility in OpenSC) in eID card standards.

[mouse07410]

@martinpaljak thank you for the answer.

But I'm missing one thing: as I understand, both Estonia and Latvia are now in the EU. Isn't there some common eID standard that allows one EU member country to verify/validate an eID issued by another member country?

[metsma]

EU regulates only cross border digital signatures but not smart cards and middleware.

[mouse07410]

EU regulates only cross border digital signatures but not smart cards and middleware

I see. Since the signatures comply with the same standard, can I assume they are ECC? Over what curves - NIST? Or Brainpool?

Also, do they validate the eID itself "abroad"? Or do they only validate documents that are digitally signed with eID?

[metsma]

Estonian cards RSA 2048 (old generation cards) and ECC 384 NIST (new RSA broken and updated cards).
Validate documents (PDF-s or ASiC-E/S signed XAdES or CAdES containers).

[frankmorgner]

xkcd

[frankmorgner]

thanks all for your help