search

gl-sergei / u2f-token

u2f token firmware for stm32f103 and efm32hg boards
GNU General Public License v3.0
339 stars 56 forks source link

Packaging into Debian #37

Closed baldurmen closed 5 years ago

baldurmen commented 5 years ago

Hi!

I would like to package u2f-token to Debian. I've already packaged the Tomu bootlader (it's waiting in the Debian NEW queue). My goal is to make using the Tomu with U2F as easy as possible.

My end goal would be to write a GUI that flashes toboot and u2f-token to a Tomu so people that can't use CLI interfaces can still use the Tomu as a U2F token.

To be able to package u2f-token in Debian, I would need to package chopstx as a separate package, since Debian doesn't allow included libraries.

I have a few questions:

  1. Do you have anything against me trying to package this in Debian? It's important for me to have an upstream that's open to the idea :D
  2. Is there a technical reason the patches you made to chopstx haven't been upstreamed (the current upstream is hosted on Debian's Gitlab instance now)? I would be much more comfortable packaging the upstream chopstx instead of the fork you currently maintain at https://github.com/gl-sergei/chopstx. If it's just because you haven't had time, I may be able to help out with doing this.
  3. Would you be open to the idea of signing future git tags? That would make it easier for everyone to verify the integrity of the code.

Thanks a lot for this software, I really enjoy using it!

gl-sergei commented 5 years ago

Hi!

I would like to package u2f-token to Debian. I've already packaged the Tomu bootlader (it's waiting in the Debian NEW queue). My goal is to make using the Tomu with U2F as easy as possible.

My end goal would be to write a GUI that flashes toboot and u2f-token to a Tomu so people that can't use CLI interfaces can still use the Tomu as a U2F token.

To be able to package u2f-token in Debian, I would need to package chopstx as a separate package, since Debian doesn't allow included libraries.

There is no such thing as dynamic linking in embedded. You could probably rework build scripts to produce static library for chopstx, but

  1. You would need to package own chopstx static library for every supported board.
  2. You will need arm gcc toolchain to produce final binary, meaning that u2f firmware package will depend on arm gcc toolchain in runtime.

I have a few questions:

  1. Do you have anything against me trying to package this in Debian? It's important for me to have an upstream that's open to the idea :D

I don't mind at all

  1. Is there a technical reason the patches you made to chopstx haven't been upstreamed (the current upstream is hosted on Debian's Gitlab instance now)? I would be much more comfortable packaging the upstream chopstx instead of the fork you currently maintain at https://github.com/gl-sergei/chopstx. If it's just because you haven't had time, I may be able to help out with doing this.

The main reason is my laziness. There is no big community around chopstx, it is not moving forward fast. I simply won't have much benefits from switching to upstream. On the other hand I can easy and fast add new boards when I have commit access.

Major differences from upstream are support for EFM32HG and a little different set of supported boards.

  1. Would you be open to the idea of signing future git tags? That would make it easier for everyone to verify the integrity of the code.

Sure, that is easy to do 😋

Thanks a lot for this software, I really enjoy using it!

baldurmen commented 5 years ago

Thanks for the answers, that's really helpful. I think I will:

  1. Package your chopstx fork as "chopstx-tomu"
  2. Package u2f-token using that as a library and only provide binaries for the tomu board and not for the others.

It makes for a somewhat messy Debian packaging experience since embedded copies need to be tracked by the security team, but I don't really see another way to do this for now.

As for chopstx not moving forward, there aren't indeed tons of people working on it, but niibe-san seems to be pretty active. He commits frequently and has released a bunch of versions lately (the latest one being Version 1.16.).