When building a dependent crate with CXXFLAGS="-flto" we see a bunch of
undefined references to functions coming from libnitrokey [0]. E.g.,

>   = note: ld: nitrokey-rs/target/debug/deps/libnitrokey-f907de21b60ae79e.rlib(nitrokey-f907de21b60ae79e.2sba6cpuq76jpx3j.rcgu.o):
>   in function `nitrokey::get_library_version':
>     nitrokey-rs/src/lib.rs:623: undefined reference to `NK_get_library_version'

It's not exactly clear why that is: All generated rlibs seem to have the
proper symbols in both cases, with and without LTO. That leaves tooling
incompatibilities as a potential culprit [1], but superficially that did
not seem to be the case either, as swapping out ar for gcc-ar did not
make any difference.
To fix this problem, this change proposes the addition of the -fno-lto
flag to the libnitrokey build. The size of the nitrocli binary built in
[message trimmed]

On 4/30/22 10:46 AM, Robin Krahl wrote:
> On 2022-04-30 15:20:15, Daniel Müller wrote:
>> Great stuff, thanks for the quick turnaround Robin! I noticed that the
>> https://git.ireas.org/ repositories (mentioned below) are outdated.
>> Should we reference the ones on sourcehut instead? Can we delete them to
>> prevent confusion?
> 
> You’re right, I noticed that too.  I forgot to update my mail generation
> script.  Will do so before the next release.  I want to keep the
> git.ireas.org repositories as a backup, and I have a cron script that
> automatically pulls in changes.  Maybe I forgot to add this repository
> to that script – I will have a look at that.

Sounds good. By the way, I just noticed that we may have inadvertently

Great stuff, thanks for the quick turnaround Robin! I noticed that the
https://git.ireas.org/ repositories (mentioned below) are outdated.
Should we reference the ones on sourcehut instead? Can we delete them to
prevent confusion?

Thanks,
Daniel

On 4/30/22 1:49 AM, Robin Krahl wrote:
> nitrokey-sys-rs v3.7.0 has been released.  It is available as a signed tag in
> the nitrokey-sys-rs Git repository:
> 	https://git.ireas.org/nitrokey-sys-rs/tag/?h=v3.7.0
> Or on crates.io:
> 	https://crates.io/crates/nitrokey-sys/3.7.0

Hi,

When I run the nitrokey-rs test suite I see the following test failures:

failures:

---- encrypted_volume stdout ----
thread 'encrypted_volume' panicked at 'assertion failed: `(left == right)`
   left: `1`,
  right: `2`', tests/device.rs:464:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

---- hidden_volume stdout ----
thread 'hidden_volume' panicked at 'assertion failed: `(left == right)`

The following changes since commit 86060cb94dea683aa767fe98171577f7a083c4df:

   Merge branch 'release-v3.6.0' (2020-09-25 01:28:54 +0200)

are available in the Git repository at:

   https://git.sr.ht/~deso/nitrokey-sys-rs

for you to fetch changes up to fd4ce5d3054b15115b771e3894f93c79801997ef:

   Update to libnitrokey v3.7 (2022-04-29 12:16:53 -0700)

----------------------------------------------------------------
Daniel Mueller (1):

On 2/27/22 11:41 AM, Robin Krahl wrote:
> On 2022-02-27 19:04:12, Daniel Müller wrote:
>> So strictly speaking we could now rip out synchronization from
>> nitrokey-test, right? I think we may want to try that and see where things
>> blow up before landing these changes. I am somewhat skeptical that all of
>> the device commands have no device-side state that could get screwed up (not
>> to speak of race conditions exposed by more frequent connects/logouts).
> 
> No.  We could change synchronization in nitrokey-test to work per device
> instead of per test, but even that might cause some issues because some
> tests try to access devices that were not passed by nitrokey-test.  We
> could probably rework these tests or add a flag for tests that cannot
> run in parallel.
> 

Looks good.

So strictly speaking we could now rip out synchronization from 
nitrokey-test, right? I think we may want to try that and see where 
things blow up before landing these changes. I am somewhat skeptical 
that all of the device commands have no device-side state that could get 
screwed up (not to speak of race conditions exposed by more frequent 
connects/logouts).

On 2/24/22 1:57 AM, Robin Krahl wrote:
> This patch adds an example that demonstrates how to connect to multiple
> devices at the same time.
> ---
>   examples/multi-otp.rs | 65 +++++++++++++++++++++++++++++++++++++++++++

Can you please clarify what purpose the Manager serves at this point? I 
was under the impression that it has become obsolete now, but I may be 
missing something.
Even if the Manager is somehow still needed, why do we need to 
synchronize accessses to it if all methods work on shared references anyway?

On 2/24/22 1:56 AM, Robin Krahl wrote:
> Previously, connecting to a device required a mutable reference to the
> Manager instance.  With this patch, we relax that requirement to a
> shared reference, making it possible to connect to multiple devices at
> the same time.  This is not supported by libnitrokey directly, but we
> can work around that by keeping track of the USB path of the currently
> connected device and re-connect if necessary.
> 

Looks good as well. Nice work! I left two comments inline.

On 2/24/22 1:56 AM, Robin Krahl wrote:
> This patch introduces a new Backend struct that manages and keeps track
> of the current device connection and a mutex storing the global Backend
> instance.  This means that all libnitrokey operations are now protected
> by that mutex.  This will allow us to implement multiple device support
> on top of libnitrokey by changing the connected libnitrokey device if
> necessary.
> ---
>   src/auth.rs           |  26 +++++++----
>   src/backend/mod.rs    | 100 ++++++++++++++++++++++++++++++------------
>   src/device/librem.rs  |  16 +++++--
>   src/device/mod.rs     |  29 ++++++------

Looks good to me.

On 2/24/22 1:55 AM, Robin Krahl wrote:
> Currently, we have three ways to connect to devices: connecting to any
> device, connecting by model and connecting by hidapi path.  This patch
> changes the backend so that these connection methods are not delegated
> to libnitrokey/nitrokey-sys directly.  Instead, we always use connection
> by path.  This allows us to keep track of the connected device in future
> patches.
> ---
>   src/backend/mod.rs | 27 ++++++++++++++++++---------
>   1 file changed, 18 insertions(+), 9 deletions(-)
> 
> diff --git a/src/backend/mod.rs b/src/backend/mod.rs