From gniibe at fsij.org  Tue Oct  2 06:48:38 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 02 Oct 2018 13:48:38 +0900
Subject: [PATCH] Fix typo in scdaemon reload command doc
In-Reply-To: <20180921131004.30165-1-utzig@apache.org>
References: <20180921131004.30165-1-utzig@apache.org>
Message-ID: <87lg7h9cnt.fsf@iwagami.gniibe.org>

Fabio Utzig <utzig at apache.org> wrote:
>  doc/stop-scdaemon.rst | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Thanks, applied.


BTW, I ordered another revision of FST-01SZ prototype, to Fusion PCBA
service, in September.

Now, I am testing previous revision of FST-01SZ prototype.  It has a
hall effect sensor.  It's MCU is GD32F103TBU6.

Here are photos:

	https://identi.ca/gniibe/image/8bsG_zEmStCGRONepwAk9g

	https://identi.ca/gniibe/image/HJ8m0jJnTVODZDdL1P7wCQ

ZL-271 is a part for USB in China, this design is de facto standard in
China.  Well, it doesn't have holes in bottom side.  I think it doesn't
conform USB standard, mechanically.

	ZL-271:
	https://detail.1688.com/offer/566197153418.html
-- 


From gniibe at fsij.org  Wed Oct  3 02:46:02 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 03 Oct 2018 09:46:02 +0900
Subject: Chopstx 1.11
Message-ID: <87bm8b3lit.fsf@iwagami.gniibe.org>

Hello,

Chopstx version 1.11 is released.  Actually, version 1.10 was released
with no announcement, then, I found a problem, which was fixed in 1.11.

Interrupt handling is changed to require call of new function
chopstx_intr_done.  This change allows flexible use of chopstx_poll;
Now, it's OK to call chopstx_poll again even when some of interrupts are
ready to be handled.  (And I found that we had spurious interrupts in
older versions, which doesn't occur any more with chopstx_intr_done).

I'm testing acknowledge button with FST-01SZ prototype.

============================  Code example
    static chopstx_intr_t intr0;
    static chopstx_intr_t intr1;

    static struct chx_poll_head *const poll_ptrs[] = {
      (struct chx_poll_head *const)&intr0,
      (struct chx_poll_head *const)&intr1,
    };

    main ()
    {
      uint32_t timer;

      hardware_init0 ();
      chopstx_claim_irq (&intr0, INTR_REQ_SOMETHING0);
      hardware_init1 ();
      chopstx_claim_irq (&intr1, INTR_REQ_SOMETHING1);

      while (1)
        {
          timer = 5000; /* 5msec, for example */

          chopstx_poll (&timer, 2, poll_ptrs);
    #if 0 /*older versions */
          /* In older versions of Chopstx,
           * all events should be handled,
           * after return of chopstx_poll and
           * before next call of chopstx_poll
           */

          if (intr0.ready)
            {
              interrupt_handler0 ();
              /* We didn't have chopstx_intr_done */
            }

          if (intr1.ready)
            {
              interrupt_handler1 ();
              /* We didn't have chopstx_intr_done */
            }

          if (intr0.ready == 0 && intr1.ready == 0)
            {
              /* timeout handling */
            }
    #else
          if (intr0.ready)
            {
              interrupt_handler0 ();
              chopstx_intr_done (&intr0);
              /* Now, it's possible not to allocate any clocks for
                 handling intr1 when intr0 is busy */
            }
          else if (intr1.ready)
            {
              interrupt_handler1 ();
              chopstx_intr_done (&intr1);
            }
          else
            {
              /* timeout handling */
            }
    #endif
        }
    }
============================

============================
Chopstx version 1.11 is released.

    tag release/1.11
    Tagger: NIIBE Yutaka <gniibe at fsij.org>
    Date:   Tue Oct 2 09:59:09 2018 +0900

    commit fffb8aa3b3731fb242d9b99f7d935d85425c1404

Chopstx is a simple RT thread library.  Major change sice version 1.9 is
interrupt handling and experiment with FST-01SZ prototype.  We have USB
bug fix for ZLP, too.
-- 


From simon at josefsson.org  Wed Oct  3 19:18:21 2018
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 03 Oct 2018 19:18:21 +0200
Subject: [PATCH] Fix typo in scdaemon reload command doc
In-Reply-To: <87lg7h9cnt.fsf@iwagami.gniibe.org> (NIIBE Yutaka's message of
 "Tue, 02 Oct 2018 13:48:38 +0900")
References: <20180921131004.30165-1-utzig@apache.org>
 <87lg7h9cnt.fsf@iwagami.gniibe.org>
Message-ID: <871s97j6ea.fsf@latte.josefsson.org>

NIIBE Yutaka <gniibe at fsij.org> writes:

> Now, I am testing previous revision of FST-01SZ prototype.  It has a
> hall effect sensor.  It's MCU is GD32F103TBU6.
>
> Here are photos:
>
> 	https://identi.ca/gniibe/image/8bsG_zEmStCGRONepwAk9g
>
> 	https://identi.ca/gniibe/image/HJ8m0jJnTVODZDdL1P7wCQ
>
> ZL-271 is a part for USB in China, this design is de facto standard in
> China.  Well, it doesn't have holes in bottom side.  I think it doesn't
> conform USB standard, mechanically.
>
> 	ZL-271:
> 	https://detail.1688.com/offer/566197153418.html

Hi.  In evaluating how to migrate from my current YubiKey nano, I
acquired some FST-01G's to experiment. I soon realized that I want the
device semi-permanently inserted in my machine, and the FST-01G is
simply too large (risk of breaking the circuit board if I carry my
laptop and hit something) and the above devices have the same problem.

What do you think of the Tomu hardware?

https://tomu.im/

It is open source hardware, has a libre bootloader, but GNUK is not (?)
ported to it.  It is a small device, so it will require removing some
GNUK features to fit, but seems feasible.  It can fit in my USB port all
the time, like the YubiKey nano.

Is there any freedom/privacy/security advantage with the FST-01G
compared to Tomu?

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20181003/49eccc44/attachment.sig>

From gniibe at fsij.org  Fri Oct 12 03:13:05 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 12 Oct 2018 10:13:05 +0900
Subject: [PATCH] Fix typo in scdaemon reload command doc
In-Reply-To: <871s97j6ea.fsf@latte.josefsson.org>
References: <20180921131004.30165-1-utzig@apache.org>
 <87lg7h9cnt.fsf@iwagami.gniibe.org> <871s97j6ea.fsf@latte.josefsson.org>
Message-ID: <87in28rmqm.fsf@iwagami.gniibe.org>

Simon Josefsson <simon at josefsson.org> writes:
> Is there any freedom/privacy/security advantage with the FST-01G
> compared to Tomu?

Well, I don't deny Tomu in a way of comparison, in public.

Instead, let me explain my points.

In my own opinion, a token should be easy to be removed off from host
computer.

The smaller the token is, the better... but not that smaller, when we
assume bringing it independently.

The background of FST-01SZ (to be smaller) is that there can be an
attack to USB-A connector, which is considered somehow practical now.
Adversary can put malicious chip to enable MiTM attack inside USB-A
connector.  <--- using a technology which enables Tomu!


One of Gnuk Token users uses magnetic USB, so that his token can be
easily removed off.  This idea can be extended to make better token
hardware, if we can assume a use case where a user permanently puts
adopter on host computer(s), and only bringing smaller token.  But...
this might make distribution more difficult, since magnet is not allowed
in a usual parcel, I'm afraid.

And... if the adopter is permanently on host computer, it is difficult
for a user when it is attacked (replaced by malicous MiTM version).


Another point:
When you permanently put your private key on your host computer, TPM
module would be your choice, if there were free implementation.
Unfortunately, I don't know such an implementation, but reverse
engineering against proprietary implementation would be possible.
--