version 0.5

This commit is contained in:
NIIBE Yutaka 2010-12-13 08:51:48 +09:00
parent 206b17fef7
commit e062532e3a
5 changed files with 18 additions and 12 deletions

View File

@ -1,3 +1,9 @@
2010-12-13 NIIBE Yutaka <gniibe@fsij.org>
* Version 0.5.
* src/usb_desc.c (gnukStringSerial): Updated.
2010-12-10 NIIBE Yutaka <gniibe@fsij.org>
* src/usb-cdc-vport.c (Virtual_Com_Port_Data_Setup)

10
NEWS
View File

@ -2,7 +2,7 @@ Gnuk NEWS - User visible changes
* Major changes in Gnuk 0.5
Released 2010-12-XX, by NIIBE Yutaka
Released 2010-12-13, by NIIBE Yutaka
** LED blink
LED blink now shows status output of the card. It shows the status of
@ -14,7 +14,7 @@ ST-Link part (with STM32F103C8T6) of STM8S Discovery board is now supported.
** Digital signing for SHA224/SHA256/SHA384/SHA512 digestInfo is now possible.
** Fixes for password management
Now, you can allow card to do digital signing multiple times with
Now, you can allow the token to do digital signing multiple times with
single authentication. You can use "forcesig" subcommand in card-edit
of GnuPG to enable the feature.
@ -26,11 +26,11 @@ Gnuk works better with GPG's in-stock protocol stack. You can do
digital signing (not decryption, key import, or get_public_key in
GPG2). For decryption, key import and get_public_key, changes are
needed for GPG (scd/ccid-driver.c) to support the case of extended
APDU. In short, you can sign with Gnuk by GPG 1.
APDU. In short, you can sign with Gnuk by GPG.
** Windows support.
Gnuk could run on MS Windows, with "usbccid" driver and "winscard"
driver.
Gnuk Token could run with GPG4WIN on MS Windows. GPG4WIN runs with
"usbccid" driver and "winscard" driver.
* Major changes in Gnuk 0.4

10
README
View File

@ -1,7 +1,7 @@
Gnuk - software for GPG USB Token
Version 0.5
2010-12-XX
2010-12-13
Niibe Yutaka
Free Software Initiative of Japan
@ -74,10 +74,10 @@ We use Olimex STM32-H103 board. We also use STM32 part of STM8S
Discovery Kit.
With DfuSe support, CQ STARM and STBee Mini are also our targets. But
those target with DfuSe are basically not for normal use but for
experiment, because it would be impossible for DfuSe to disable read
from flash. For real use, kill DfuSe and enable read protect using
JTAG debugger.
those targets with DfuSe are basically not for normal use but for
experiments, because it would be impossible for DfuSe to disable read
from flash. For real use, please consider killing DfuSe and enable
read protect using JTAG debugger.
I think that it could run on Olimex STM32-P103, or STBee too.
Besides, we are porting it to STM32 Primer 2.

View File

@ -228,7 +228,7 @@ volatile enum icc_state icc_state;
/*
* ATR (Answer To Reset) string
*
* TS = 0x3B: Direct conversion
* TS = 0x3b: Direct conversion
* T0 = 0xda: TA1, TC1 and TD1 follow, 10 historical bytes
* TA1 = 0x11: FI=1, DI=1
* TC1 = 0xff

View File

@ -220,7 +220,7 @@ static const uint8_t gnukStringSerial[] = {
8*2+2, /* bLength */
USB_STRING_DESCRIPTOR_TYPE, /* bDescriptorType */
'2', 0, '0', 0, '1', 0, '0', 0,
'1', 0, '1', 0, '1', 0, '2', 0
'1', 0, '2', 0, '1', 0, '3', 0
};
const ONE_DESCRIPTOR Device_Descriptor = {