From gniibe at fsij.org  Sat Mar  2 01:00:43 2019
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Sat, 02 Mar 2019 09:00:43 +0900
Subject: Chopstx 1.14
Message-ID: <87zhqem9g4.fsf@c720>

Hello,

Chopstx 1.14 is released.

	tag release/1.14
	Tagger: NIIBE Yutaka <gniibe at fsij.org>
	Date:   Sat Mar 2 08:49:13 2019 +0900
	commit aeea3c31f8dab3e5920e4c35f6199b519f928c79


The change is only USART driver for STM32.

	* Enhancement of driver: USART for STM32
	Now, it supports smartcard communication.


With this, I started developing smartcard reader.  See:

    https://identi.ca/gniibe/image/C6-E_MdgTUyH-fclCh_ONQ
-- 


From dmanriq at gmail.com  Sat Mar  2 02:12:38 2019
From: dmanriq at gmail.com (Daniel Manrique)
Date: Fri, 1 Mar 2019 20:12:38 -0500
Subject: Private data objects
Message-ID: <CAF680ueg41125jRCd42PY9jFuexAqhNczZvrGtfc0EWTAe1tRw@mail.gmail.com>

(I have tried to send this message before but didn't seem to make it
through. My apologies if you receive it twice.)

Hi,

I've been testing gnuk on a st-link stick for some weeks now. In general it
works pretty well. I'm very happy with it and very grateful for Niibe's
great work.

One thing that I've noted is that gnuk doesn't seem to implement the
private data objects (DO1-4) from the openpgp card specification. In my
case that's what currently prevents me to fully adopt gnuk instead of still
relying on a smartcard.

My question is: are there plans to implement the private data objects? how
difficult would be to do it?

Thank you very much for your help!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20190301/403567f0/attachment.html>

From gniibe at fsij.org  Mon Mar  4 01:01:52 2019
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 04 Mar 2019 09:01:52 +0900
Subject: Private data objects
In-Reply-To: <CAF680ueg41125jRCd42PY9jFuexAqhNczZvrGtfc0EWTAe1tRw@mail.gmail.com>
References: <CAF680ueg41125jRCd42PY9jFuexAqhNczZvrGtfc0EWTAe1tRw@mail.gmail.com>
Message-ID: <87a7iby0b3.fsf@iwagami.gniibe.org>

Daniel Manrique <dmanriq at gmail.com> wrote:
> One thing that I've noted is that gnuk doesn't seem to implement the
> private data objects (DO1-4) from the openpgp card specification. In my
> case that's what currently prevents me to fully adopt gnuk instead of still
> relying on a smartcard.
>
> My question is: are there plans to implement the private data objects? how
> difficult would be to do it?

Please note that Gnuk doesn't implement all (possible) features of
OpenPGPcard specification.  Keeping out some feature(s) makes sense.
Keeping the implementation stupid and simpler is also important.

Well, for example, I somehow regret my adding support of ACK button
feature (though I don't have any idea removing that).  I did that
because the feature was added in V3 specification, and I was not sure if
it were useful.  For six-month experience, my own judgement is that it's
not that useful for my use case.


Back to the specific feature, let me explain about DO1-4 and certificate
object(s).  I don't support those objects because of three reasons;
there is no good definition how those can be used and useful.
Implementing those objects interferes lower-level communication, and
there may be not enough room to keep those objects in flash memory
anyway.

Certificate object support is now compile time option.  Until V2
specification, it is a single object.  In V3 specification, it is
enhanced to three objects.  Gnuk can support one, but writing the object
is supported incompatible way while reading is compatible.


If you want to support DO1-4 objects (with the limitation of less than
256 bytes), I'd suggest start your experiment from enhancing Gnuk by
adding support of read-only compile-time defined objects.  Then, you can
proceed adding flash memory management for those objects... to support
writing objects.

Supporting larger size, I think that we need to modify our
implementation of communication protocol (of ISO 7816), or we need to
support larger-size object by introducing some
peculiar/incompatible/ugly method like we did for certificate object.
The former would require larger surgery of implementation.
-- 


From gniibe at fsij.org  Mon Mar  4 04:08:40 2019
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 04 Mar 2019 12:08:40 +0900
Subject: Gnuk 1.2.14
Message-ID: <875zszxrnr.fsf@iwagami.gniibe.org>

Hello,

Gnuk 1.2.14 is released.

	tag release/1.2.14
	Tagger: NIIBE Yutaka <gniibe at fsij.org>
	Date:   Mon Mar 4 12:01:38 2019 +0900
	commit 177ef67edfa2306c2a369a037362385c354083e1

The changes are:

* Timeout for ACK button support

* Upgrade of Chopstx to 1.14

-- 


From email at kmkcl.de  Mon Mar  4 05:43:46 2019
From: email at kmkcl.de (=?UTF-8?Q?Karsten_M=c3=bcller?=)
Date: Mon, 4 Mar 2019 05:43:46 +0100
Subject: gnuk with GD32F103
In-Reply-To: <871s5jbsxw.fsf@fsij.org>
References: <d40b3d22-d43f-f006-f220-c1c321bfbc50@kmkcl.de>
 <871s5jbsxw.fsf@fsij.org>
Message-ID: <ebbb5529-fdd3-d286-7237-3efd7fb07167@kmkcl.de>

Hello,

thank you very much for your response. At this weekend I had some time
to do some further trials...
So I adapted the design to FST01-SZ. But it does not work and I have no
clue what to do next. 

That is my current status:

* PCB is based on FST-01, without SPI-Chip (and other pin for USB-EN -
like nitrokey_start)
* Software compiles and works on STM32F103
* on PCB with GD32F103, programming with a simple hello world program
works and also all connections (pin toggling with test program) and
oscillator/PLL... - so chip seems OK
* Software is compiled with --target=FST01_SZ (and check, that it is
compiled with -DMHZ=96)
* with logic analyzer no USB-Packets are detected (in contrast to
STM32F103 version)
* I also test with and without USB-EN pin (once in software - comment
out define, once in hardware by desoldering resistor)
* on STM32 it only works with both enabled, on GD32 nothing works.

I wonder, because for me it seems that USB-EN is not really necessary?
(FST01_SZ version does not have this pin)

My suggestion is, that either hardware or software (maybe compile
process?) is faulty...
I know, it is against the idea/license to share binarys, but would it be
possible to get a working binary for testing ( I think, vidpid equals
zero would be OK, because there has to be any USB communication which
can be seen on logic analyzer) or a other method to test my compiled
software?

I would be happy for any hints or ideas for target-oriented debugging.

sincerely,
Karsten M?ller



From gniibe at fsij.org  Mon Mar  4 06:36:09 2019
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 04 Mar 2019 14:36:09 +0900
Subject: gnuk with GD32F103
In-Reply-To: <ebbb5529-fdd3-d286-7237-3efd7fb07167@kmkcl.de>
References: <d40b3d22-d43f-f006-f220-c1c321bfbc50@kmkcl.de>
 <871s5jbsxw.fsf@fsij.org> <ebbb5529-fdd3-d286-7237-3efd7fb07167@kmkcl.de>
Message-ID: <874l8jmcae.fsf@c720>

Karsten M?ller <email at kmkcl.de> wrote:
> * PCB is based on FST-01, without SPI-Chip (and other pin for USB-EN -
> like nitrokey_start)

FST-01G and FST-01SZ don't use USB-EN any more.  I removed the pin
because it is not needed.  I know a design with USB-EN, like Maple-Mini,
and that is a reason why FST-01 has that.

The intended use of USB-EN in FST-01 was for a device to ask host to do
re-enumeration.  For this purpose, simply driving USB signals (D+ and
D-) to GND is actually OK.  For strict conformance to the USB
specification, it's better supporting high impedance state of D+.  But,
(for me), the fixed pull-up of D+ can be acceptable, as long as it
works.

In short, I suggest removing USB-EN.  Please have a look at FST-01SZ
schematics, it pulls-up D+ line to +3V3 directly (no USB-EN control at
all).

> * I also test with and without USB-EN pin (once in software - comment
> out define, once in hardware by desoldering resistor)

The resistor should be there to pull up D+ line to +3V3.  Having USB-EN
means, it is configurable (pull-up to +3V3 or not).  "Removing" should
be being fixed to pull up to +3V3, not removing the registor itself.

In chopstx/board/board-fst-01.h, hardware pin of USB-EN pin (PA10) is
designated to the pin which usb_cable_config function controls.  In
chopstx/board/board-fst-01g.h and chopstx/board/board-fst-01sz.h, there
is nothing.

So, if you use FST-01SZ configuration for a hardware with USB-EN, USB
functionality is simply not available.  To enable USB functionality, you
need to put a resistor (1K5) to pull up to +3V3.
-- 


From email at kmkcl.de  Tue Mar  5 19:07:52 2019
From: email at kmkcl.de (=?UTF-8?Q?Karsten_M=c3=bcller?=)
Date: Tue, 5 Mar 2019 19:07:52 +0100
Subject: gnuk with GD32F103
In-Reply-To: <874l8jmcae.fsf@c720>
References: <d40b3d22-d43f-f006-f220-c1c321bfbc50@kmkcl.de>
 <871s5jbsxw.fsf@fsij.org> <ebbb5529-fdd3-d286-7237-3efd7fb07167@kmkcl.de>
 <874l8jmcae.fsf@c720>
Message-ID: <637eb289-98c4-4bc8-90e4-e474641c3560@kmkcl.de>

Hello,

thank you very much, I am happy that it works now.

Am 04.03.19 um 06:36 schrieb NIIBE Yutaka:
> FST-01G and FST-01SZ don't use USB-EN any more.  I removed the pin
> because it is not needed.  I know a design with USB-EN, like Maple-Mini,
> and that is a reason why FST-01 has that.
>
> The intended use of USB-EN in FST-01 was for a device to ask host to do
> re-enumeration.  For this purpose, simply driving USB signals (D+ and
> D-) to GND is actually OK.  For strict conformance to the USB
> specification, it's better supporting high impedance state of D+.  But,
> (for me), the fixed pull-up of D+ can be acceptable, as long as it
> works.

Thanks for explanation.

> In short, I suggest removing USB-EN.  Please have a look at FST-01SZ
> schematics, it pulls-up D+ line to +3V3 directly (no USB-EN control at
> all).
While reading I realized that ESD-Protection NUF2221W1 has an integrated
pullup.

When designing PCB I choose an other TVS diode and use discrete series
resistors (like in nitrokey start) but I overlooked pullup resistance in
datasheet.

Thanks,

Karsten




From ardavast at noiseoverip.com  Thu Mar 14 16:00:24 2019
From: ardavast at noiseoverip.com (Ardavast Dayleryan)
Date: Thu, 14 Mar 2019 17:00:24 +0200
Subject: ST-LINK/V2 ID 0000:0000
Message-ID: <CAG=VjEn39xAO=5Or1Z6CtFB=CgbC==sEsCd_gnhvLUPuNHbaBQ@mail.gmail.com>

Hello,

I saw that there was a similar thread here before, but I still can't
understand what am I doing wrong.
The versions are:
gnuk: 177ef67edfa2306c2a369a037362385c354083e1 (release/1.2.14)
chopstx: aeea3c31f8dab3e5920e4c35f6199b519f928c79 (release/1.14)

I run Ubuntu 18.04, so I used the toolchain from here:
https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads
I compiled gnuk with these commands:
./configure --vidpid=234b:0000 --target=ST_DONGLE
make
CROSS=/home/ardavast/Downloads/gcc-arm-none-eabi-8-2018-q4-major/bin/arm-none-eabi-
build/gnuk-vidpid.bin

I flashed an ST-LINK/V2 device with OpenOCD:
reset halt
stm32f1x unlock 0
reset halt
stm32f1x mass_erase 0
flash write_bank 0 /home/ardavast/src/gnuk-orig/src/build/gnuk-vidpid.bin 0
stm32f1x lock 0
reset halt

After plugging the device, I get the following:
dmesg:
[ 8192.537428] usb 3-3: new full-speed USB device number 45 using xhci_hcd
[ 8192.686923] usb 3-3: New USB device found, idVendor=0000, idProduct=0000
[ 8192.686928] usb 3-3: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 8192.686931] usb 3-3: Product: Gnuk Token
[ 8192.686934] usb 3-3: Manufacturer: Free Software Initiative of Japan
[ 8192.686937] usb 3-3: SerialNumber: FSIJ-1.2.14-67023331

usb-devices:
T:  Bus=03 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 45 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev=00.00
S:  Manufacturer=Free Software Initiative of Japan
S:  Product=Gnuk Token
S:  SerialNumber=FSIJ-1.2.14-67023331
C:  #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=0b(scard) Sub=00 Prot=00 Driver=(none)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20190314/9cca068a/attachment.html>

From peter at digitalbrains.com  Thu Mar 14 18:02:22 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Thu, 14 Mar 2019 18:02:22 +0100
Subject: ST-LINK/V2 ID 0000:0000
In-Reply-To: <CAG=VjEn39xAO=5Or1Z6CtFB=CgbC==sEsCd_gnhvLUPuNHbaBQ@mail.gmail.com>
References: <CAG=VjEn39xAO=5Or1Z6CtFB=CgbC==sEsCd_gnhvLUPuNHbaBQ@mail.gmail.com>
Message-ID: <7fbbc9b1-82eb-e426-9dbc-d6f307a35414@digitalbrains.com>

On 14/03/2019 16:00, Ardavast Dayleryan wrote:
> make CROSS=/home/ardavast/Downloads/gcc-arm-none-eabi-8-2018-q4-major/bin/arm-none-eabi- build/gnuk-vidpid.bin

Ooh... that target is a leftover from before the targets were
gnuk-no-vidpid.elf and gnuk.elf. You should probably omit the target
completely for future compatibility, but the current default target is
'all'.

I suggest doing:

make CROSS=/home/ardavast/Downloads/gcc-arm-none-eabi-8-2018-q4-major/bin/arm-none-eabi-

But this is currently the same:

make CROSS=/home/ardavast/Downloads/gcc-arm-none-eabi-8-2018-q4-major/bin/arm-none-eabi- all

Then you get build/gnuk.bin to flash to the chip, rather than
build/gnuk-vidpid.bin.

Background: it was decided to rename the old gnuk.elf target that
omitted the VID/PID to gnuk-novidpid.elf, and the
gnuk-vidpid.{elf,bin,hex} targets that contain the VID/PID to
gnuk.{elf,bin,hex}. 

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From peter at digitalbrains.com  Thu Mar 14 18:07:18 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Thu, 14 Mar 2019 18:07:18 +0100
Subject: ST-LINK/V2 ID 0000:0000
In-Reply-To: <7fbbc9b1-82eb-e426-9dbc-d6f307a35414@digitalbrains.com>
References: <CAG=VjEn39xAO=5Or1Z6CtFB=CgbC==sEsCd_gnhvLUPuNHbaBQ@mail.gmail.com>
 <7fbbc9b1-82eb-e426-9dbc-d6f307a35414@digitalbrains.com>
Message-ID: <9ffabf8a-3598-4e4f-697b-2c09e6a6e405@digitalbrains.com>

On 14/03/2019 18:02, Peter Lebbing wrote:
> Ooh... that target is a leftover from before the targets were
> gnuk-no-vidpid.elf and gnuk.elf.

I jumped to conclusions; I reckoned it was accidentally still in the Makefile, 
but it is not there. I see a ChangeLog entry for version 1.2.10 released on 
2018-05-10 that mentions removing the target. So that raises the question: what 
version are you trying to compile? I strongly suspect you should stick to the 
latest released version to get relevant bug fixes. And a pre-1.2.10 version 
would really be very old indeed.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From peter at digitalbrains.com  Thu Mar 14 18:19:04 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Thu, 14 Mar 2019 18:19:04 +0100
Subject: ST-LINK/V2 ID 0000:0000
In-Reply-To: <9ffabf8a-3598-4e4f-697b-2c09e6a6e405@digitalbrains.com>
References: <CAG=VjEn39xAO=5Or1Z6CtFB=CgbC==sEsCd_gnhvLUPuNHbaBQ@mail.gmail.com>
 <7fbbc9b1-82eb-e426-9dbc-d6f307a35414@digitalbrains.com>
 <9ffabf8a-3598-4e4f-697b-2c09e6a6e405@digitalbrains.com>
Message-ID: <82b4bf87-6de6-d8c7-78e7-8b6cc26b4934@digitalbrains.com>

On 14/03/2019 18:07, Peter Lebbing wrote:
> So that raises the question: what version are you trying to compile?

Wow, I'm trying to be helpful but I'm generating a lot of noise. You already 
mentioned that, and I can reproduce it.

GNU make will automatically compute the target gnuk-vidpin.bin and intermediate 
gnuk-vidpid.elf, and the chopstx rules.mk is written in such a way that it 
actually wildcards any elf file to build the project! So you could write 
build/my-cool-project.bin and it would actually build something equal to 
gnuk-no-vidpid.elf! Haha.

So it's back to my suggestion in the first mail: don't give a target, or if you 
feel you must, specify 'all'. For curiosity's sake, build/gnuk.bin will also work.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From ardavast at noiseoverip.com  Fri Mar 15 18:24:35 2019
From: ardavast at noiseoverip.com (Ardavast Dayleryan)
Date: Fri, 15 Mar 2019 19:24:35 +0200
Subject: ST-LINK/V2 ID 0000:0000
In-Reply-To: <82b4bf87-6de6-d8c7-78e7-8b6cc26b4934@digitalbrains.com>
References: <CAG=VjEn39xAO=5Or1Z6CtFB=CgbC==sEsCd_gnhvLUPuNHbaBQ@mail.gmail.com>
 <7fbbc9b1-82eb-e426-9dbc-d6f307a35414@digitalbrains.com>
 <9ffabf8a-3598-4e4f-697b-2c09e6a6e405@digitalbrains.com>
 <82b4bf87-6de6-d8c7-78e7-8b6cc26b4934@digitalbrains.com>
Message-ID: <CAG=VjEnQzoE=x_4Nj5xmeUWLtFdWGG_g-KWhgZ8hnyF2MKdSkA@mail.gmail.com>

Thank you!

I was able to build a working version of gnuk.bin with:
./configure --vidpid=234b:0000 --target=ST_DONGLE
make
CROSS=/home/ardavast/Downloads/gcc-arm-none-eabi-8-2018-q4-major/bin/arm-none-eabi-

The only problem was that just setting the CROSS variable is not enough,
because on line 17 in binary-edit.sh, arm-none-eabi-objdump is called
directly.  So I had to expose it in $PATH, otherwise the build fails
somewhat
silently (exit status 0):

cp -p build/gnuk-no-vidpid.elf build/gnuk.elf
env FILE="build/gnuk.elf" bash put-vid-pid-ver.sh
binary-edit.sh: line 17: arm-none-eabi-objdump: command not found
Offset is
/home/ardavast/Downloads/gcc-arm-none-eabi-8-2018-q4-major/bin/arm-none-eabi-objcopy
-O ihex build/gnuk.elf build/gnuk.hex
/home/ardavast/Downloads/gcc-arm-none-eabi-8-2018-q4-major/bin/arm-none-eabi-objcopy
-O binary build/gnuk.elf build/gnuk.bin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20190315/e183f9b1/attachment.html>

From peter at digitalbrains.com  Fri Mar 15 20:19:05 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 15 Mar 2019 20:19:05 +0100
Subject: ST-LINK/V2 ID 0000:0000
In-Reply-To: <CAG=VjEnQzoE=x_4Nj5xmeUWLtFdWGG_g-KWhgZ8hnyF2MKdSkA@mail.gmail.com>
References: <CAG=VjEn39xAO=5Or1Z6CtFB=CgbC==sEsCd_gnhvLUPuNHbaBQ@mail.gmail.com>
 <7fbbc9b1-82eb-e426-9dbc-d6f307a35414@digitalbrains.com>
 <9ffabf8a-3598-4e4f-697b-2c09e6a6e405@digitalbrains.com>
 <82b4bf87-6de6-d8c7-78e7-8b6cc26b4934@digitalbrains.com>
 <CAG=VjEnQzoE=x_4Nj5xmeUWLtFdWGG_g-KWhgZ8hnyF2MKdSkA@mail.gmail.com>
Message-ID: <bd2c3f13-a13b-b560-d85e-f441acff2d81@digitalbrains.com>

On 15/03/2019 18:24, Ardavast Dayleryan wrote:
> I was able to build a working version of gnuk.bin with:

Ah, that's good to hear!

> The only problem was that just setting the CROSS variable is not enough,
> because on line 17 in binary-edit.sh, arm-none-eabi-objdump is called
> directly.

The way I see it, the CROSS variable is currently not used to indicate
/which/ cross-compiler to use, but rather to indicate /whether/ to
cross-compile or compile natively. The latter is for debugging purely on
the host without additional hardware.[1]

Since put-vid-pid-ver.sh is not needed for the native version, it is
implied that it is for cross-compilation to ARM, so there was no need to
depend on some variable CROSS. In fact, the variable is not available in
the environment, it is only available in the Makefile currently.

This all could be fixed, but first it should be decided whether the GnuK
project /wants/ to support specifying different cross-compilers and the
burden of complexity that comes with it (testing functionality before
release and such).

One area that could be improved is the failure mode when the shell
script does not find a required executable. Failing loudly is always
better than failing inconspicuously, IMO.

HTH,

Peter.

[1] I can also imagine a scenario where a virtual machine has no access
to the private key material, but is able to use an on-disk key of the
host or a different VM through emulation of a GnuK.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20190315/bf768e78/attachment.sig>

From e.rigas at cranfield.ac.uk  Wed Mar 20 16:55:06 2019
From: e.rigas at cranfield.ac.uk (Rigas, Evangelos)
Date: Wed, 20 Mar 2019 15:55:06 +0000
Subject: Alternative Gnuk token board design
Message-ID: <3d2ed970587b366c5ba78c6d3a694b2bae704a4a.camel@cranfield.ac.uk>

Hello all,

First, I would like to thank you for your great work.

I was insipired by Niibe's work on FST-01 token and Gnuk and decided to
make my own (a good excuse to get familiarised with Kicad).

My main goal was to make the token more compact, reduce the BOM
slightly and add the Hall effect sensor from FST-01SZ (The board uses
the STM32F103TB as FST-01G). 

You can find the design files here: https://git.rnd2.org/erigas/gnukey
(pcb) and https://git.rnd2.org/erigas/gnukey-ds (case).

I tried Gnuk and GnuPG (from Git) and it works perfectly (even the ACK 
button).

You can find the changes to chopstx here: 
https://git.rnd2.org/erigas/chopstx/src/branch/gnukey 
in case you want to include it to the project. 
In that case I will try to get a PID from pid.codes as mentioned in a
previous thread (Binary distribution).


Kind regards,
Evangelos Rigas

From e.rigas at cranfield.ac.uk  Wed Mar 20 15:46:56 2019
From: e.rigas at cranfield.ac.uk (Rigas, Evangelos)
Date: Wed, 20 Mar 2019 14:46:56 +0000
Subject: Alternative Gnuk token board design
Message-ID: <a5d3e2602bc17b86ca6a0744477ac7510207b327.camel@cranfield.ac.uk>

Hello all,

First, I would like to thank you for your great work.

I was insipired by Niibe's work on FST-01 token and Gnuk and decided to
make my own (a good excuse to get familiarised with Kicad).

My main goal was to make the token more compact, reduce the BOM
slightly and add the Hall effect sensor from FST-01SZ (The board uses
the STM32F103TB as FST-01G). 

You can find the design files here: https://git.rnd2.org/erigas/gnukey
(pcb) and https://git.rnd2.org/erigas/gnukey-ds (case).

I tried Gnuk and GnuPG (from Git) and it works perfectly (even the ACK 
button).

You can find the changes to chopstx here: 
https://git.rnd2.org/erigas/chopstx/src/branch/gnukey 
in case you want to include it to the project. 
In that case I will try to get a PID from pid.codes as mentioned in a
previous thread (Binary distribution).


Kind regards,
Evangelos Rigas

From peter at digitalbrains.com  Thu Mar 21 13:43:18 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Thu, 21 Mar 2019 13:43:18 +0100
Subject: Alternative Gnuk token board design
In-Reply-To: <3d2ed970587b366c5ba78c6d3a694b2bae704a4a.camel@cranfield.ac.uk>
References: <3d2ed970587b366c5ba78c6d3a694b2bae704a4a.camel@cranfield.ac.uk>
Message-ID: <70945deb-8f3c-00f9-713b-52d6776f8bdc@digitalbrains.com>

On 20/03/2019 16:55, Rigas, Evangelos wrote:
> You can find the design files here: https://git.rnd2.org/erigas/gnukey
> (pcb) and https://git.rnd2.org/erigas/gnukey-ds (case).

That looks really nice, thanks for expanding the ecosystem!

And a nice touch to include a design for the pogo pins.

But based on what I've read with regard to edge connectors on PCB's, you
should probably use hard gold for the fingers of the connector.
Otherwise they will wear out rather quickly and might leave conductive
"dust" in your connectors. I'm just warning you about this possibility
in case you did not know, as I don't see a comment in your Git
repository.

Having a PCB fab do hard gold on a part of the PCB boosts the price by
quite a bit, unfortunately.

HTH,

Peter.

PS: With regard to programming connections, Niibe writes at [1] about
using "Mac-8's XC-2" connectors. I have yet to find anything like that
that will be shipped to The Netherlands! They look really useful, but
are made of unobtainium.

[1] <http://www.gniibe.org/memo/development/fst-01/dongle/fst-01-swd-connection.html>

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20190321/7e8916fd/attachment.sig>

From e.rigas at cranfield.ac.uk  Thu Mar 21 15:37:48 2019
From: e.rigas at cranfield.ac.uk (Rigas, Evangelos)
Date: Thu, 21 Mar 2019 14:37:48 +0000
Subject: Alternative Gnuk token board design
In-Reply-To: <70945deb-8f3c-00f9-713b-52d6776f8bdc@digitalbrains.com>
References: <3d2ed970587b366c5ba78c6d3a694b2bae704a4a.camel@cranfield.ac.uk>
 <70945deb-8f3c-00f9-713b-52d6776f8bdc@digitalbrains.com>
Message-ID: <1cfce0607966df198256553eb9dd43ac14d1d1ce.camel@cranfield.ac.uk>

On Thu, 2019-03-21 at 13:43 +0100, Peter Lebbing wrote:
> And a nice touch to include a design for the pogo pins.

Thanks Peter.
I plan to design a PCB (some sort of a jig) for programming. That way
it will be easier to make, instead of relying on expensive 3D printers.

As for the gold platting of the connector, you are right. That is why I
ordered the PCB with ENIG (Immersion Gold).
Is not the same quality as hard gold, but an order of magnitude
cheaper.

In addition, ENIG offers better planarity on the exposed pads which
helps with SMD soldering; compared to the default hot air solder
leveling (HASL) process.

Cheers,

Evangelos

From mike at sowbug.com  Fri Mar 22 00:18:24 2019
From: mike at sowbug.com (Mike Tsao)
Date: Thu, 21 Mar 2019 16:18:24 -0700
Subject: Alternative Gnuk token board design
In-Reply-To: <1cfce0607966df198256553eb9dd43ac14d1d1ce.camel@cranfield.ac.uk>
References: <3d2ed970587b366c5ba78c6d3a694b2bae704a4a.camel@cranfield.ac.uk>
 <70945deb-8f3c-00f9-713b-52d6776f8bdc@digitalbrains.com>
 <1cfce0607966df198256553eb9dd43ac14d1d1ce.camel@cranfield.ac.uk>
Message-ID: <CACi+kjogiaLeogQXXwMGGxcxnxsCedHSn7D-m5gWN2bvzt9n8w@mail.gmail.com>

Evangelos:

I did a project a few years ago that has a similar form factor to yours:
https://github.com/sowbug/weblight

A notable difference is that the Weblight board can be inserted in either
top or bottom orientation in the Type A slot, a little like Type C but
through the magic of diodes rather than symmetric design of the female
connector. This was more important for my project because it had a visual
component to it, but I'm sure users would appreciate the flexibility. Plus
you're already solder-masking both sides of the PCB, so it's no additional
manufacturing cost except for the diodes.

As you can see in the board order I did
<https://github.com/sowbug/weblight/blob/master/hardware/mfg/production/1.0/pcbcart-pcb-order-160930.pdf>,
I chose ENIG finish with 2.0mm thickness. We ended up ordering another
1,000 in addition to that order, and we've never had a complaint about
proper fit in USB ports.

I also took the ProtoProg
<http://protofusion.org/wordpress/2013/05/open-hardware-pogo-pin-programmer/>
concept
for the pogo programming, ordering the PCBs from OSH Park
<https://oshpark.com/shared_projects/fqvxyzoH> (I'm in the US, so that was
a perfect option for me). That tool is AVR-based, so it's not applicable to
your project except to the extent you might want to copy that design and
alter it for STM32 programming.

Mike

On Thu, Mar 21, 2019 at 7:37 AM Rigas, Evangelos <e.rigas at cranfield.ac.uk>
wrote:

> On Thu, 2019-03-21 at 13:43 +0100, Peter Lebbing wrote:
> > And a nice touch to include a design for the pogo pins.
>
> Thanks Peter.
> I plan to design a PCB (some sort of a jig) for programming. That way
> it will be easier to make, instead of relying on expensive 3D printers.
>
> As for the gold platting of the connector, you are right. That is why I
> ordered the PCB with ENIG (Immersion Gold).
> Is not the same quality as hard gold, but an order of magnitude
> cheaper.
>
> In addition, ENIG offers better planarity on the exposed pads which
> helps with SMD soldering; compared to the default hot air solder
> leveling (HASL) process.
>
> Cheers,
>
> Evangelos
> _______________________________________________
> Gnuk-users mailing list
> Gnuk-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnuk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20190321/e95ece16/attachment.html>

From matias at imap.cc  Sat Mar 23 00:12:18 2019
From: matias at imap.cc (Matias N.)
Date: Fri, 22 Mar 2019 19:12:18 -0400
Subject: Porting to NuttX / composite mode / U2F
Message-ID: <cf037883-61d5-4a27-907c-bf027626fea1@www.fastmail.com>

Hi,
I was wondering whether you think it should be possible (and not too much work) to port the application logic to the NuttX RTOS, instead of using chopstx. I ask because it would be interesting to add more functionality to the device by taking advantage of NuttX features, such as USB composite mode. This would then allow to integrate other modes such as U2F in the same device (by taking advantage of existing https://github.com/gl-sergei/u2f-token).

I understand that U2F functionality is not planned for gnuk itself, right?

Best,
Matias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20190322/5ff00d32/attachment.html>

From gniibe at fsij.org  Mon Mar 25 02:08:15 2019
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 25 Mar 2019 10:08:15 +0900
Subject: Porting to NuttX / composite mode / U2F
In-Reply-To: <cf037883-61d5-4a27-907c-bf027626fea1@www.fastmail.com>
References: <cf037883-61d5-4a27-907c-bf027626fea1@www.fastmail.com>
Message-ID: <87bm1z7ocg.fsf@iwagami.gniibe.org>

"Matias N." <matias at imap.cc> wrote:
> I was wondering whether you think it should be possible (and not too
> much work) to port the application logic to the NuttX RTOS, instead of
> using chopstx.

I think it should be possible (if an RTOS supports something like POSIX
threads).  I don't know how much work is needed.  You can examine
GNU/Linux port.

But... please note that the exact reason why I use Chopstx is less
functionality.  I don't have a plan to support other RTOS for Gnuk.

> I ask because it would be interesting to add more functionality to the
> device by taking advantage of NuttX features, such as USB composite
> mode.

In my opinion, USB composite device is not good for security device.

Apparently, users have a problem with old implementation (Yubikey NEO),
when they want to use multiple features simultaneously (like OTP and
OpenPGPcard), see my comment at:

    https://dev.gnupg.org/T4225#119535

While Yubikey NEO supports "mode", it seems Yubikey 4 (and later)
supports "applications".  I only have experience with Yubikey NEO.  I'll
try Yubikey 4.  Perhaps, things are now improved.

> I understand that U2F functionality is not planned for gnuk itself, right?

I don't have any plan for U2F.  My opinion is it is good to have
seperate device for U2F.  If it is in a single device, it's better to
use applications interchangeably (not simultaneously), or you would need
a driver which is dedicated to the device to serve multiple features
securely.
-- 


From e.rigas at cranfield.ac.uk  Mon Mar 25 11:57:21 2019
From: e.rigas at cranfield.ac.uk (Rigas, Evangelos)
Date: Mon, 25 Mar 2019 10:57:21 +0000
Subject: Alternative Gnuk token board design
In-Reply-To: <CACi+kjogiaLeogQXXwMGGxcxnxsCedHSn7D-m5gWN2bvzt9n8w@mail.gmail.com>
References: <3d2ed970587b366c5ba78c6d3a694b2bae704a4a.camel@cranfield.ac.uk>
 <70945deb-8f3c-00f9-713b-52d6776f8bdc@digitalbrains.com>
 <1cfce0607966df198256553eb9dd43ac14d1d1ce.camel@cranfield.ac.uk>
 <CACi+kjogiaLeogQXXwMGGxcxnxsCedHSn7D-m5gWN2bvzt9n8w@mail.gmail.com>
Message-ID: <aeb6a26807d5424024f09afb4eb3f5ba55248c6f.camel@cranfield.ac.uk>

Hi Mike,

I had a look on weblight, the trick with diodes is realy nice.
As for the ProtoProg, I had a similar design in mind.

Thanks, for the links.

Evangelos

On Thu, 2019-03-21 at 16:18 -0700, Mike Tsao wrote:
Evangelos:

I did a project a few years ago that has a similar form factor to yours: https://github.com/sowbug/weblight

A notable difference is that the Weblight board can be inserted in either top or bottom orientation in the Type A slot, a little like Type C but through the magic of diodes rather than symmetric design of the female connector. This was more important for my project because it had a visual component to it, but I'm sure users would appreciate the flexibility. Plus you're already solder-masking both sides of the PCB, so it's no additional manufacturing cost except for the diodes.

As you can see in the board order I did<https://github.com/sowbug/weblight/blob/master/hardware/mfg/production/1.0/pcbcart-pcb-order-160930.pdf>, I chose ENIG finish with 2.0mm thickness. We ended up ordering another 1,000 in addition to that order, and we've never had a complaint about proper fit in USB ports.

I also took the ProtoProg<http://protofusion.org/wordpress/2013/05/open-hardware-pogo-pin-programmer/> concept for the pogo programming, ordering the PCBs from OSH Park<https://oshpark.com/shared_projects/fqvxyzoH> (I'm in the US, so that was a perfect option for me). That tool is AVR-based, so it's not applicable to your project except to the extent you might want to copy that design and alter it for STM32 programming.

Mike

On Thu, Mar 21, 2019 at 7:37 AM Rigas, Evangelos <e.rigas at cranfield.ac.uk<mailto:e.rigas at cranfield.ac.uk>> wrote:
On Thu, 2019-03-21 at 13:43 +0100, Peter Lebbing wrote:
> And a nice touch to include a design for the pogo pins.

Thanks Peter.
I plan to design a PCB (some sort of a jig) for programming. That way
it will be easier to make, instead of relying on expensive 3D printers.

As for the gold platting of the connector, you are right. That is why I
ordered the PCB with ENIG (Immersion Gold).
Is not the same quality as hard gold, but an order of magnitude
cheaper.

In addition, ENIG offers better planarity on the exposed pads which
helps with SMD soldering; compared to the default hot air solder
leveling (HASL) process.

Cheers,

Evangelos
_______________________________________________
Gnuk-users mailing list
Gnuk-users at gnupg.org<mailto:Gnuk-users at gnupg.org>
https://lists.gnupg.org/mailman/listinfo/gnuk-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20190325/e7734ac0/attachment.html>

From matias at imap.cc  Mon Mar 25 22:29:29 2019
From: matias at imap.cc (Matias N.)
Date: Mon, 25 Mar 2019 17:29:29 -0400
Subject: Can't reflash ST-Link dongle
Message-ID: <ee2b5b56-b994-42c8-aebd-92a37df393f0@www.fastmail.com>

Hi,
I was using gnuk on my st-link dongle for some time. I tried to update using gnuk scripts and my board stopped responding. Since I figured I messed up doing this I went ahead and recompiled gnuk and flashed using another st-link dongle. Flashing works however onces re-plugged the device cannot reenumerate. I get:

[531046.370438] usb usb3-port4: unable to enumerate USB device
[531051.092809] usb 3-3: USB disconnect, device number 14
[531058.670516] usb 3-4: new full-speed USB device number 39 using xhci_hcd
[531058.798583] usb 3-4: device descriptor read/64, error -71
[531059.034586] usb 3-4: device descriptor read/64, error -71
[531059.270525] usb 3-4: new full-speed USB device number 40 using xhci_hcd
[531059.398550] usb 3-4: device descriptor read/64, error -71
[531059.638560] usb 3-4: device descriptor read/64, error -71
[531059.746567] usb usb3-port4: attempt power cycle
[531060.398516] usb 3-4: new full-speed USB device number 41 using xhci_hcd
[531060.398622] usb 3-4: Device not responding to setup address.

Since I figured maybe I failed programming, I downloaded a DFU binary configured for the led on PA9 (as is the case for this dongle) and this works perfectly (right after flashing, the LED starts to blink). So, I'm thinking this could be a problem then with the gnuk binary I'm obtaining. I tried with lastest release and also with the version I had, 1.2.8.

I'm doing (for 1.2.8):
./configure --vidpid=234b:0000 --target=ST_DONGLE
make build/gnuk-vidpid.bin
openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg -c init -c "reset halt" -c "flash write_image erase build/gnuk-vidpid.bin 0x08000000" -c "verify_image build/gnuk-vidpid.bin" -c "reset run" -c "shutdown"

I'm not sure if this is due to the board not being in reset or something (since the dongle does not have the reset pin mapped). However, if that's the case, I don't understand why flashing the DFU binary works.

Maybe I could ask if someone can send me a precompiled (working) binary for the ST-link dongle so I can try and flash that.

Thanks,
Matias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20190325/09d17354/attachment.html>

From matias at imap.cc  Mon Mar 25 23:47:57 2019
From: matias at imap.cc (Matias N.)
Date: Mon, 25 Mar 2019 18:47:57 -0400
Subject: Can't reflash ST-Link dongle
In-Reply-To: <ee2b5b56-b994-42c8-aebd-92a37df393f0@www.fastmail.com>
References: <ee2b5b56-b994-42c8-aebd-92a37df393f0@www.fastmail.com>
Message-ID: <596f0139-96a9-49d4-a0b9-a5bb5d78eddb@www.fastmail.com>

Actually, I found the image I originally flashed the first time I used gnuk (version 1.2.8) and it worked perfectly. It seems that I cannot build a valid .bin image. I'm on Ubuntu 18.04, btw. Anyone else had any problems creating a good binary for the st-link dongle?

On Mon, Mar 25, 2019, at 18:29, Matias N. wrote:
> Hi,
> I was using gnuk on my st-link dongle for some time. I tried to update using gnuk scripts and my board stopped responding. Since I figured I messed up doing this I went ahead and recompiled gnuk and flashed using another st-link dongle. Flashing works however onces re-plugged the device cannot reenumerate. I get:
> 
> [531046.370438] usb usb3-port4: unable to enumerate USB device
> [531051.092809] usb 3-3: USB disconnect, device number 14
> [531058.670516] usb 3-4: new full-speed USB device number 39 using xhci_hcd
> [531058.798583] usb 3-4: device descriptor read/64, error -71
> [531059.034586] usb 3-4: device descriptor read/64, error -71
> [531059.270525] usb 3-4: new full-speed USB device number 40 using xhci_hcd
> [531059.398550] usb 3-4: device descriptor read/64, error -71
> [531059.638560] usb 3-4: device descriptor read/64, error -71
> [531059.746567] usb usb3-port4: attempt power cycle
> [531060.398516] usb 3-4: new full-speed USB device number 41 using xhci_hcd
> [531060.398622] usb 3-4: Device not responding to setup address.
> 
> Since I figured maybe I failed programming, I downloaded a DFU binary configured for the led on PA9 (as is the case for this dongle) and this works perfectly (right after flashing, the LED starts to blink). So, I'm thinking this could be a problem then with the gnuk binary I'm obtaining. I tried with lastest release and also with the version I had, 1.2.8.
> 
> I'm doing (for 1.2.8):
> ./configure --vidpid=234b:0000 --target=ST_DONGLE
> make build/gnuk-vidpid.bin
> openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg -c init -c "reset halt" -c "flash write_image erase build/gnuk-vidpid.bin 0x08000000" -c "verify_image build/gnuk-vidpid.bin" -c "reset run" -c "shutdown"
> 
> I'm not sure if this is due to the board not being in reset or something (since the dongle does not have the reset pin mapped). However, if that's the case, I don't understand why flashing the DFU binary works.
> 
> Maybe I could ask if someone can send me a precompiled (working) binary for the ST-link dongle so I can try and flash that.
> 
> Thanks,
> Matias
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20190325/fa164e95/attachment.html>

From matias at imap.cc  Tue Mar 26 01:58:07 2019
From: matias at imap.cc (Matias N.)
Date: Mon, 25 Mar 2019 20:58:07 -0400
Subject: Can't reflash ST-Link dongle
In-Reply-To: <596f0139-96a9-49d4-a0b9-a5bb5d78eddb@www.fastmail.com>
References: <ee2b5b56-b994-42c8-aebd-92a37df393f0@www.fastmail.com>
 <596f0139-96a9-49d4-a0b9-a5bb5d78eddb@www.fastmail.com>
Message-ID: <9caa205c-12c0-4f4e-8f5e-7240824a5044@www.fastmail.com>

Ok, I just confirmed that there's a problem with Ubuntu 18.04 build environment (gcc version or other component) since by compiling inside a docker with an older release (I used gcc:7 image) I could build both the old and the current version and works OK.

I wouldn't know how this can be debugged, but I think it is something to consider.

Best,
Matias

On Mon, Mar 25, 2019, at 19:47, Matias N. wrote:
> Actually, I found the image I originally flashed the first time I used gnuk (version 1.2.8) and it worked perfectly. It seems that I cannot build a valid .bin image. I'm on Ubuntu 18.04, btw. Anyone else had any problems creating a good binary for the st-link dongle?
> 
> On Mon, Mar 25, 2019, at 18:29, Matias N. wrote:
>> Hi,
>> I was using gnuk on my st-link dongle for some time. I tried to update using gnuk scripts and my board stopped responding. Since I figured I messed up doing this I went ahead and recompiled gnuk and flashed using another st-link dongle. Flashing works however onces re-plugged the device cannot reenumerate. I get:
>> 
>> [531046.370438] usb usb3-port4: unable to enumerate USB device
>> [531051.092809] usb 3-3: USB disconnect, device number 14
>> [531058.670516] usb 3-4: new full-speed USB device number 39 using xhci_hcd
>> [531058.798583] usb 3-4: device descriptor read/64, error -71
>> [531059.034586] usb 3-4: device descriptor read/64, error -71
>> [531059.270525] usb 3-4: new full-speed USB device number 40 using xhci_hcd
>> [531059.398550] usb 3-4: device descriptor read/64, error -71
>> [531059.638560] usb 3-4: device descriptor read/64, error -71
>> [531059.746567] usb usb3-port4: attempt power cycle
>> [531060.398516] usb 3-4: new full-speed USB device number 41 using xhci_hcd
>> [531060.398622] usb 3-4: Device not responding to setup address.
>> 
>> Since I figured maybe I failed programming, I downloaded a DFU binary configured for the led on PA9 (as is the case for this dongle) and this works perfectly (right after flashing, the LED starts to blink). So, I'm thinking this could be a problem then with the gnuk binary I'm obtaining. I tried with lastest release and also with the version I had, 1.2.8.
>> 
>> I'm doing (for 1.2.8):
>> ./configure --vidpid=234b:0000 --target=ST_DONGLE
>> make build/gnuk-vidpid.bin
>> openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg -c init -c "reset halt" -c "flash write_image erase build/gnuk-vidpid.bin 0x08000000" -c "verify_image build/gnuk-vidpid.bin" -c "reset run" -c "shutdown"
>> 
>> I'm not sure if this is due to the board not being in reset or something (since the dongle does not have the reset pin mapped). However, if that's the case, I don't understand why flashing the DFU binary works.
>> 
>> Maybe I could ask if someone can send me a precompiled (working) binary for the ST-link dongle so I can try and flash that.
>> 
>> Thanks,
>> Matias
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20190325/1abc063d/attachment.html>

From ardavast at noiseoverip.com  Tue Mar 26 09:42:44 2019
From: ardavast at noiseoverip.com (Ardavast Dayleryan)
Date: Tue, 26 Mar 2019 10:42:44 +0200
Subject: Can't reflash ST-Link dongle
In-Reply-To: <9caa205c-12c0-4f4e-8f5e-7240824a5044@www.fastmail.com>
References: <ee2b5b56-b994-42c8-aebd-92a37df393f0@www.fastmail.com>
 <596f0139-96a9-49d4-a0b9-a5bb5d78eddb@www.fastmail.com>
 <9caa205c-12c0-4f4e-8f5e-7240824a5044@www.fastmail.com>
Message-ID: <CAG=VjEkyHe_J8ii9Pn3LJghc7e6iSGcjCAfhUKNSQ8Br6KzwSg@mail.gmail.com>

Hello, I had exactly the same problem a couple of weeks ago, and I was able
to
solve it after discussing it here on this mailing list.
This thread was helpful:
https://lists.gnupg.org/pipermail/gnuk-users/2019-January/000164.html
You can also see my thread here:
https://lists.gnupg.org/pipermail/gnuk-users/2019-March/000191.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20190326/957274bf/attachment.html>

From matias at imap.cc  Tue Mar 26 15:54:32 2019
From: matias at imap.cc (Matias N.)
Date: Tue, 26 Mar 2019 10:54:32 -0400
Subject: Can't reflash ST-Link dongle
In-Reply-To: <CAG=VjEkyHe_J8ii9Pn3LJghc7e6iSGcjCAfhUKNSQ8Br6KzwSg@mail.gmail.com>
References: <ee2b5b56-b994-42c8-aebd-92a37df393f0@www.fastmail.com>
 <596f0139-96a9-49d4-a0b9-a5bb5d78eddb@www.fastmail.com>
 <9caa205c-12c0-4f4e-8f5e-7240824a5044@www.fastmail.com>
 <CAG=VjEkyHe_J8ii9Pn3LJghc7e6iSGcjCAfhUKNSQ8Br6KzwSg@mail.gmail.com>
Message-ID: <379daedc-e133-47fa-a120-063704055a22@www.fastmail.com>

Thanks for confirming. Too bad the bug is reported and not yet fixed.
Maybe it is worth adding a notice on the gnuk README? Also a mention to the compilation via docker with specific
version can help avoid similar issues in the future.

Best,
Matias

On Tue, Mar 26, 2019, at 05:43, Ardavast Dayleryan wrote:
> Hello, I had exactly the same problem a couple of weeks ago, and I was able to
> solve it after discussing it here on this mailing list.
> This thread was helpful: https://lists.gnupg.org/pipermail/gnuk-users/2019-January/000164.html
> You can also see my thread here: https://lists.gnupg.org/pipermail/gnuk-users/2019-March/000191.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20190326/348f3626/attachment.html>