blockchaincommons / seedtool-cli

Cryptographic Seed Tool for the command line

🌱 Blockchain Commons seedtool-cli

by Wolf McNally and Christopher Allen

•    part of the crypto commons technology family
• part of the gordian technology family

Introduction

seedtool is a command-line tool for creating and transforming cryptographic seeds of the sort commonly used by blockchain applications.

It exercises the various cryptographic C libraries created by Blockchain Commons, as described in the Dependencies section.

Status - Feature-Complete Beta

Seedtool is now considered feature-complete and is entering beta-level testing.

Dependencies

Seedtool exercises the following Blockchain Commons libraries:

• bc-crypto-base
• bc-shamir
• bc-sskr
• bc-bip39
• bc-ur

It also requires the following additional programs:

• GNU argp
• CBOR Lite

Tool Dependencies

To build seedtool you'll need to use the following tools:

• autotools - Gnu Build System from Free Software Foundation (intro).

Recommended Installation instructions

The dependencies will be automatically installed as submodules when you run the build script. This is the recommended way to install.

Build with Docker

Install docker and run:

# Build the image
$ docker build -t seedtool-cli .
# Run the container
$ docker run --rm -it seedtool-cli --help

Build on MacOS

$ brew install autoconf automake libtool

You must then download or clone this repo. Afterward, cd into the repo directory and:

$ ./build.sh
$ sudo make install

Build on Linux

Make sure you have llvm/clang, libc++ and libc++abi installed, all with a minimum recommended version 10.

Build on Ubuntu and Debian

$ sudo apt install build-essential

$ wget https://apt.llvm.org/llvm.sh
$ chmod +x llvm.sh
$ sudo apt install lsb-release wget software-properties-common
$ sudo ./llvm.sh 10  # version 10

$ sudo apt-get install libc++-10-dev libc++abi-10-dev

$ sudo apt-get install git
$ git clone https://github.com/BlockchainCommons/seedtool-cli.git
$ cd seedtool-cli/
$ export CC="clang-10" && export CXX="clang++-10" && ./build.sh
$ sudo make install

Build on Windows

See instructions here.

Alternative Installation Instructions

The following sequence does not install the dependencies from submodules; instead they must be installed in the usual places on the build system, otherwise the ./configure step below will fail.

$ ./configure
$ make
$ sudo make install

Note: On Linux the first step is ./configure CC=clang-10 CXX=clang++-10

Incremental Build Instructions

If you wish to make changes to the source code and rebuild:

# Make source changes
$ source set_build_paths.sh # sets shell variables used by make
$ make clean # If you want a clean build
$ make

Usage Instructions

See usage examples for examples of using seedtool.

Full Documentation

See MANUAL.md for details, many more examples, and version history.

Notes for Maintainers

Before accepting a PR that can affect build or unit tests, make sure the following sequence of commands succeeds:

$ ./build.sh
$ make lint
$ make check
$ make distclean

make lint uses Cppcheck to perform static analysis on the code. All PRs should pass with no warnings.

Related Projects

• LetheKit is a parallel project that uses many of the same libraries, but in hardware.
• URKit is another example of our bc-ur universal-reference library.

Origin, Authors, Copyright & Licenses

Unless otherwise noted (either in this /README.md or in the file's header comments) the contents of this repository are Copyright © 2020 by Blockchain Commons, LLC, and are licensed under the spdx:BSD-2-Clause Plus Patent License.

In most cases, the authors, copyright, and license for each file reside in header comments in the source code. When it does not we have attempted to attribute it accurately in the table below.

This table below also establishes provenance (repository of origin, permalink, and commit id) for files included from repositories that are outside of this repository. Contributors to these files are listed in the commit history for each repository, first with changes found in the commit history of this repo, then in changes in the commit history of their repo of their origin.

File	From	Commit	Authors & Copyright (c)	License
hkdf.c	rustyrussell/ccan	d07f742	2016 Rusty Russell 2020 Wolf McNally	MIT
hkdf.h	rustyrussell/ccan	d07f742	2016 Rusty Russell	MIT
randombytes.c	dsprenkels/randombytes	6db39aa	2017-2019 Daan Sprenkels	MIT
randombytes.h	dsprenkels/randombytes	19fd002	2017-2019 Daan Sprenkels	MIT

Tool Dependencies

To build seedtool you'll need to use the following tools:

• autotools - Gnu Build System from Free Software Foundation (intro).

Financial Support

Seedtool is a project of Blockchain Commons. We are proudly a "not-for-profit" social benefit corporation committed to open source & open development. Our work is funded entirely by donations and collaborative partnerships with people like you. Every contribution will be spent on building open tools, technologies, and techniques that sustain and advance blockchain and internet security infrastructure and promote an open web.

To financially support further development of Seedtool and other projects, please consider becoming a Patron of Blockchain Commons through ongoing monthly patronage as a GitHub Sponsor. You can also support Blockchain Commons with bitcoins at our BTCPay Server.

Contributing

We encourage public contributions through issues and pull-requests! Please review CONTRIBUTING.md for details on our development process. All contributions to this repository require a GPG signed Contributor License Agreement.

Discussions

The best place to talk about Blockchain Commons and its projects is in our GitHub Discussions areas.

Gordian User Community. For users of the Gordian reference apps, including Gordian Coordinator, Gordian Seed Tool, Gordian Server, Gordian Wallet, and SpotBit as well as our whole series of CLI apps. This is a place to talk about bug reports and feature requests as well as to explore how our reference apps embody the Gordian Principles.

Blockchain Commons Discussions. For developers, interns, and patrons of Blockchain Commons, please use the discussions area of the Community repo to talk about general Blockchain Commons issues, the intern program, or topics other than those covered by the Gordian Developer Community or the Gordian User Community.

Other Questions & Problems

As an open-source, open-development community, Blockchain Commons does not have the resources to provide direct support of our projects. Please consider the discussions area as a locale where you might get answers to questions. Alternatively, please use this repository's issues feature. Unfortunately, we can not make any promises on response time.

If your company requires support to use our projects, please feel free to contact us directly about options. We may be able to offer you a contract for support from one of our contributors, or we might be able to point you to another entity who can offer the contractual support that you need.

Credits

The following people directly contributed to this repository. You can add your name here by getting involved — the first step is to learn how to contribute from our CONTRIBUTING.md documentation.

Name	Role	Github	Email	GPG Fingerprint
Christopher Allen	Principal Architect	@ChristopherA	<[email protected]>	FDFE 14A5 4ECB 30FC 5D22 74EF F8D3 6C91 3574 05ED
Wolf McNally	Project Lead	@WolfMcNally	<[email protected]>	9436 52EE 3844 1760 C3DC  3536 4B6C 2FCF 8947 80AE

Responsible Disclosure

We want to keep all our software safe for everyone. If you have discovered a security vulnerability, we appreciate your help in disclosing it to us in a responsible manner. We are unfortunately not able to offer bug bounties at this time.

We do ask that you offer us good faith and use best efforts not to leak information or harm any user, their data, or our developer community. Please give us a reasonable amount of time to fix the issue before you publish it. Do not defraud our users or us in the process of discovery. We promise not to bring legal action against researchers who point out a problem provided they do their best to follow the these guidelines.

Reporting a Vulnerability

Please report suspected security vulnerabilities in private via email to [email protected] (do not use this email for support). Please do NOT create publicly viewable issues for suspected security vulnerabilities.

The following keys may be used to communicate sensitive information to developers:

Name	Fingerprint
Christopher Allen	FDFE 14A5 4ECB 30FC 5D22 74EF F8D3 6C91 3574 05ED

You can import a key by running the following command with that individual’s fingerprint: gpg --recv-keys "<fingerprint>" Ensure that you put quotes around fingerprints that contain spaces.

seedtool-cli's Issues

Default count should be 32, appears to be 16

The default output units for seedtool is defined in help as 32, but default output appears to be 16:

% seedtool --version
0.3.0
% seedtool --help
Usage: seedtool [OPTION...] INPUT
Converts cryptographic seeds between various forms.

  -c, --count=1-64           The number of output units (default: 32)
…
% seedtool
b07d0c0b7a5f32550bea1aaac779d5be
% seedtool -c 32
1d3cb84dd5e6de5723e510368fb533a61e5f2fbde9cf83a393cef73032960fd7
% seedtool -c 64
c8a89861175b665a68e9347844634b65996f3c5c12fc60fd54c9fb92e04b5e7c2729e87b26736e51cb7b6edff3469383e2202e604bf586130625ddab1d30bb3b

What about encoding a shard as bech32?

After seeing the sample output of:

seedtool --out bech32

I'm not sure -out bech32 is always correct. Can you output a Shamir shard as bech32? You should also be able to do that. Which leads to the problem of how seedtool knows that a seed put into bech32 gets the prefix seed, but a Shamir shard -out bech32 gets another prefix, like skr0 (secret key recovery 0 as we know there is VSS on the way). That is why I've been puzzling no prefixes and version numbers.

Ideas on how we can also output a shard as bech32 and not mnemonics?

-- Christopher Allen

Reproducible build

https://reproducible-builds.org/

Related to #44

Add build details to --help

Add the specific build number to --help using the same kind of hook that #LetheKit uses.

-- Christopher Allen

Deprecate SLIP39 in seedtool

As per comments in #26, we should probably deprecate SLIP39 in seedtool as it is risky for users.

Building on macOS 12.3 Intel Fails

On macOS Monterey 12.3 on a MacBook Pro (13-inch, 2020, Four Thunderbolt 3 ports), with all system updates, and Xcode Version 13.3 (13E113), building seedtool-cli is failing.

I have done brew install autoconf automake libtool shunit2 with no errors.

Doing ./build.sh starts ok, but then fails with

seedtool-cli % git pull
…
seedtool-cli % git clean --ffdx
…
seedtool-cli % ./build.sh
…
Undefined symbols for architecture x86_64:
  "_argp_program_bug_address", referenced from:
      __help in libargp.a(argp-help.o)
  "_strchrnul", referenced from:
      _argp_args_usage in libargp.a(argp-help.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [argp-test] Error 1
make: *** [install-recursive] Error 1

seedtool-cli %

I have also tried make clean.

Error parsing hex input when number of bytes is not divisible by 4

When entering an hex seed input with 14, 18, 22, 26 or 30 bytes, seedtool returns garbage data, or internal error.

Entering any seed with length between 16-32 that is also divisible by 4 works well (i.e., 16, 20, 24, 28, 32).

I guess there's an unbound string checking somewhere, but wasn't able to find in a cursory look at the code.

Example

Seed is 28 hex characters in length == 14 bytes:

$ ./src/seedtool --in hex --out bip39 1234567890123456789012345678
pb`

$ ./src/seedtool --in hex --out bip39 1234567890123456789012345678
!vz

$ ./src/seedtool --in hex --out bip39 1234567890123456789012345678
./src/seedtool: An internal error occurred.

Seed is 32 hex characters == 16 bytes:

$ ./src/seedtool --in hex --out bip39 12345678901234567890123456789012
banana pencil owner cage cash clinic time across crowd record catch caution

Post-build seedtool regression test script

I'd love at some point some type of regression-test.sh shell script that would test all of the functionality of seedtool, both with deterministic randonmess, and with true randomness, ideally in some way such that it round-trips in multiple passes to verify its own operations.

This can be derived from the code unit testing, but ideally does more and tests the system as a whole in such as way that it isn't testing the invidual pieces, but the whole using the results of the math to be the confirmation.

Allow BIP39 <-> SSKR

Why not allow input of bip-39 and output of sskr (and vice versa)?

SSKR seems to be the best option right now to use a somewhat standardized format for shamir secrets that is not company dependent like Trezors SLIP-39.

It would be helpful to allow conversion form bip-39 to sskr as now i have to take the extra step of converting to HEX manually first.

Docker build fails

Hey, first of all thank you for the amazing software that you are providing. I was able to compile everything up to bc-sskr, so I have:

• libbc-crypto-base.a
• libbc-shamir.a
• libbc-sskr.a

However when trying to build the docker image, the last step of the build stage fails with:

<git:(master)> docker build -t seedtool-cli:latest .
...
41.53 /usr/bin/ld: /seedtool-cli/deps/bc-ur/src/ur.cpp:22: undefined reference to `std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::~basic_string()'
41.54 /usr/bin/ld: /seedtool-cli/sysroot/lib/libbc-ur.a(random-sampler.o): in function `std::__1::vector<int, std::__1::allocator<int> >::__recommend(unsigned long) const':
41.54 /usr/lib/llvm-10/bin/../include/c++/v1/vector:1027: undefined reference to `std::__1::__vector_base_common<true>::__throw_length_error() const'
41.54 /usr/bin/ld: /seedtool-cli/sysroot/lib/libbc-ur.a(random-sampler.o): in function `std::__1::vector<int, std::__1::allocator<int> >::__vallocate(unsigned long)':
41.54 /usr/lib/llvm-10/bin/../include/c++/v1/vector:993: undefined reference to `std::__1::__vector_base_common<true>::__throw_length_error() const'
41.55 clang: error: linker command failed with exit code 1 (use -v to see invocation)
41.55 make[1]: *** [<builtin>: seedtool] Error 1
41.55 make[1]: Leaving directory '/seedtool-cli/src'
41.55 make: *** [Makefile:38: check] Error 2
------
Dockerfile:18
--------------------
  16 |     WORKDIR /seedtool-cli
  17 |     RUN git submodule update --init --recursive
  18 | >>> RUN CC="clang-10" CXX="clang++-10" ./build.sh
  19 |     
  20 |     # Export built executable to a minimal runtime image and run as an unprivileged
--------------------
ERROR: failed to solve: process "/bin/sh -c CC=\"clang-10\" CXX=\"clang++-10\" ./build.sh" did not complete successfully: exit code: 2

BIP39 to SSKR and reverse

Please allow for direct conversion of BIP39 to SSKR shares and vice versa, without having to manually convert to and from hex. Currently it sates seedtool: Input format bip39 cannot be used with output format sskr

Add Dockerfile to make the build process more easy, secure, and hermetic

This issue is relevant to all BlockchainCommons tools.
The current build process requires installing llvm 10 (and possibly other dependencies in the future), which requires build privileges and is not always desirable. In addition, building is not hermetic, it can be affected be anything already installed on the build machine.
A better approach, both in terms of build reproduciblity and user friendliness, is providing a Dockerfile and/or using a build system such as Bazel.

BIP85 support

Please add BIP85 support

Add link to GitHub Issues page for support in seedtool --help

In seedtool --help, instead of sending email to my blockchain commons email address, add link to GitHub Issues instead. The README.md should do the same if it doesn't already.

Extra credit if you can figure out why some links in Apple Terminal.app are right-clickable and some are not — love to add that if we can figure out a way that doesn't break linux cli.

-- Christopher Allen

SLIP39 + BIP39 + SSKR secret sizes

Thank you for this great project.

This is not really an issue so I'm sorry if there's a better place for questions and I missed it.

I implemented this small variation of SLIP39 that would use BIP39 mnemonics directly instead of SLIP39 master keys that are incompatible with BIP39 and, by consequence, most wallets.

But I noticed the SLIP39/BIP39 secrets it generates are 20 words long and the secrets seedtool generates are 29 words long. Why is that? It might seem like a small difference, but this is a practical issue because capsules and steel plates often don't support 29 words.

support direct conversion from sskr to bip39

I confirmed this can convert a file of sskr shares back to bip39 correctly:

cat shares | seedtool --in sskr --out hex | seedtool --in hex --out bip39

but when trying to convert the same sskr shares file directly to bip39, I get:

cat shares | seedtool --in sskr --out bip39
seedtool: Input format sskr cannot be used with output format bip39

Is there a reason for this?

Being able to convert directly from sskr to bip39 seems like one of the most common use cases. I want to provide sskr shares to my family members in case of an emergency and have a single command they can come together and run to convert this to a bip39 seed phrase that can be used by many wallets.

Proper Deterministic Randomness for Shamir & sskr

A challenge for bc-shamir is that it also needs randomness separately from seed randomness, so that when testing on different implementaions, when using deterministic flag, the exact same values should be output for all the shares, even though with real shamir randomness all the variants will restore back to the correct seed

So we need a way to expand the randomness in a deterministic way for testing multiple implementations of sskr against each other.

Can't build a static executable

Static executables are great for easy deployment in air gapped machines, like a laptop running Tails, so I think they should be supported, if not the default.
I tried to build using something like CFLAGS="-static" CXXFLAGS="-static" LDFLAGS="-static" ./build.sh, but it fails because libgcc_s.a doesn't exist, only libgcc_s.so.

Build fails on Fedora 29

$ cat /etc/redhat-release 
Fedora release 29 (Twenty Nine)

cc  -I/home/user/bonsai/bc-seedtool-cli/libs/include -g -O0   -c -o test-utils.o test-utils.c
In file included from test-utils.c:8:
test-utils.h:14:19: error: unknown type name ‘uint8_t’; did you mean ‘u_int8_t’?
 char* data_to_hex(uint8_t* in, size_t insz);
                   ^~~~~~~
                   u_int8_t

test-utils.c:72:16: warning: implicit declaration of function ‘hex_to_data’ [-Wimplicit-function-declaration]
   size_t len = hex_to_data(hex, &out);
                ^~~~~~~~~~~
test-utils.c:73:17: warning: implicit declaration of function ‘data_to_hex’; did you mean ‘test_hex’? [-Wimplicit-function-declaration]
   char* reout = data_to_hex(out, len);
                 ^~~~~~~~~~~
                 test_hex

make[1]: Entering directory '/home/user/bonsai/bc-seedtool-cli/deps/bc-slip39/test'
cc  -I/home/user/bonsai/bc-seedtool-cli/libs/include -g -O0   -c -o test.o test.c
test.c: In function ‘test_generate_and_combine’:
test.c:61:23: warning: implicit declaration of function ‘strlen’ [-Wimplicit-function-declaration]
   size_t secret_len = strlen(secret) + 1;
                       ^~~~~~
test.c:61:23: warning: incompatible implicit declaration of built-in function ‘strlen’
test.c:61:23: note: include ‘<string.h>’ or provide a declaration of ‘strlen’
test.c:6:1:
+#include <string.h>
 
test.c:61:23:
   size_t secret_len = strlen(secret) + 1;
                       ^~~~~~
cd ../src && make libbc-slip39.a

cc  -L/home/user/bonsai/bc-seedtool-cli/libs/lib -lbc-crypto-base -lbc-shamir  test.o ../src/libbc-slip39.a test-utils.o   -o test
/usr/bin/ld: ../src/libbc-slip39.a(mnemonics.o): in function `generate_shards':
/home/user/bonsai/bc-seedtool-cli/deps/bc-slip39/src/mnemonics.c:218: undefined reference to `split_secret'
/usr/bin/ld: /home/user/bonsai/bc-seedtool-cli/deps/bc-slip39/src/mnemonics.c:227: undefined reference to `split_secret'
/usr/bin/ld: ../src/libbc-slip39.a(mnemonics.o): in function `combine_shards_internal':
/home/user/bonsai/bc-seedtool-cli/deps/bc-slip39/src/mnemonics.c:470: undefined reference to `recover_secret'
/usr/bin/ld: /home/user/bonsai/bc-seedtool-cli/deps/bc-slip39/src/mnemonics.c:485: undefined reference to `recover_secret'
/usr/bin/ld: ../src/libbc-slip39.a(encrypt.o): in function `round_function':
/home/user/bonsai/bc-seedtool-cli/deps/bc-slip39/src/encrypt.c:75: undefined reference to `pbkdf2_hmac_sha256'
collect2: error: ld returned 1 exit status

make[1]: Entering directory '/home/user/bonsai/bc-seedtool-cli/deps/bc-bip39/test'
cc  -I/home/user/bonsai/bc-seedtool-cli/libs/include -g -O0   -c -o test.o test.c
test.c: In function ‘_test_mnemonic_from_word’:
test.c:21:18: warning: implicit declaration of function ‘strlen’ [-Wimplicit-function-declaration]
         result = strlen(mnemonic) == 0;
                  ^~~~~~
test.c:21:18: warning: incompatible implicit declaration of built-in function ‘strlen’
test.c:21:18: note: include ‘<string.h>’ or provide a declaration of ‘strlen’
test.c:14:1:
+#include <string.h>
 
test.c:21:18:
         result = strlen(mnemonic) == 0;
                  ^~~~~~
In file included from test.c:9:
test.c: In function ‘test_seed_from_string’:
test.c:73:12: warning: implicit declaration of function ‘memcmp’ [-Wimplicit-function-declaration]
     assert(memcmp(ref_secret, seed, secret_len) == 0);
            ^~~~~~
test.c:85:16: warning: implicit declaration of function ‘strcmp’ [-Wimplicit-function-declaration]
         assert(strcmp(string, ref_string) == 0);
                ^~~~~~

cc  -L/home/user/bonsai/bc-seedtool-cli/libs/lib -lbc-crypto-base  test.o ../src/libbc-bip39.a test-utils.o   -o test
/usr/bin/ld: ../src/libbc-bip39.a(bip39.o): in function `compute_checksum':
/home/user/bonsai/bc-seedtool-cli/deps/bc-bip39/src/bip39.c:175: undefined reference to `sha256_Raw'
/usr/bin/ld: ../src/libbc-bip39.a(bip39.o): in function `bip39_seed_from_string':
/home/user/bonsai/bc-seedtool-cli/deps/bc-bip39/src/bip39.c:519: undefined reference to `sha256_Raw'
collect2: error: ld returned 1 exit status
make[1]: *** [<builtin>: test] Error 1

if gcc -DHAVE_CONFIG_H -I. -I. -I.   -I.  -I/home/user/bonsai/bc-seedtool-cli/libs/include -ggdb3 -Wall -W  -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes  -Waggregate-return  -Wpointer-arith -Wbad-function-cast -Wnested-externs -MT argp-help.o -MD -MP -MF ".deps/argp-help.Tpo" -c -o argp-help.o argp-help.c; \
then mv -f ".deps/argp-help.Tpo" ".deps/argp-help.Po"; else rm -f ".deps/argp-help.Tpo"; exit 1; fi
argp-help.c: In function ‘fill_in_uparams’:
argp-help.c:233:15: warning: pointer targets in passing argument 1 of ‘atoi’ differ in signedness [-Wpointer-sign]
   val = atoi (arg);
               ^~~
In file included from argp-help.c:45:
/usr/include/stdlib.h:104:12: note: expected ‘const char *’ but argument is of type ‘const unsigned char *’
 extern int atoi (const char *__nptr)
            ^~~~
argp-help.c:241:17: warning: pointer targets in passing argument 1 of ‘strncmp’ differ in signedness [-Wpointer-sign]
     && strncmp (var, un->name, var_len) == 0)
                 ^~~
In file included from argp-help.c:46:
/usr/include/string.h:139:12: note: expected ‘const char *’ but argument is of type ‘const unsigned char *’
 extern int strncmp (const char *__s1, const char *__s2, size_t __n)
            ^~~~~~~
argp-help.c: In function ‘until_short’:
argp-help.c:606:71: warning: unused parameter ‘real’ [-Wunused-parameter]
 until_short (const struct argp_option *opt, const struct argp_option *real UNUSED,
                                             ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
argp-help.c:607:19: warning: unused parameter ‘domain’ [-Wunused-parameter]
       const char *domain UNUSED, void *cookie UNUSED)
       ~~~~~~~~~~~~^~~~~~
argp-help.c:607:40: warning: unused parameter ‘cookie’ [-Wunused-parameter]
       const char *domain UNUSED, void *cookie UNUSED)
                                  ~~~~~~^~~~~~
argp-help.c: In function ‘arg’:
argp-help.c:952:18: warning: unused parameter ‘domain’ [-Wunused-parameter]
      const char *domain UNUSED, argp_fmtstream_t stream)
      ~~~~~~~~~~~~^~~~~~
argp-help.c: In function ‘add_argless_short_opt’:
argp-help.c:1257:22: warning: unused parameter ‘domain’ [-Wunused-parameter]
          const char *domain UNUSED, void *cookie)
          ~~~~~~~~~~~~^~~~~~
argp-help.c: In function ‘usage_argful_short_opt’:
argp-help.c:1271:16: warning: unused parameter ‘domain’ [-Wunused-parameter]
    const char *domain UNUSED, void *cookie)
    ~~~~~~~~~~~~^~~~~~
argp-help.c: In function ‘usage_long_opt’:
argp-help.c:1303:15: warning: unused parameter ‘domain’ [-Wunused-parameter]
   const char *domain UNUSED, void *cookie)
   ~~~~~~~~~~~~^~~~~~
if gcc -DHAVE_CONFIG_H -I. -I. -I.   -I.  -I/home/user/bonsai/bc-seedtool-cli/libs/include -ggdb3 -Wall -W  -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes  -Waggregate-return  -Wpointer-arith -Wbad-function-cast -Wnested-externs -MT argp-parse.o -MD -MP -MF ".deps/argp-parse.Tpo" -c -o argp-parse.o argp-parse.c; \
then mv -f ".deps/argp-parse.Tpo" ".deps/argp-parse.Po"; else rm -f ".deps/argp-parse.Tpo"; exit 1; fi
argp-parse.c: In function ‘argp_version_parser’:
argp-parse.c:172:37: warning: unused parameter ‘arg’ [-Wunused-parameter]
 argp_version_parser (int key, char *arg UNUSED, struct argp_state *state)
                               ~~~~~~^~~
argp-parse.c: At top level:
argp-parse.c:1279:1: error: attributes should be specified before the declarator in a function definition
 void
 ^~~~
argp-parse.c:1285:1: error: attributes should be specified before the declarator in a function definition
 int
 ^~~
argp-parse.c:1299:1: error: attributes should be specified before the declarator in a function definition
 int
 ^~~
make[1]: *** [Makefile:302: argp-parse.o] Error 1
make[1]: Leaving directory '/home/user/bonsai/bc-seedtool-cli/deps/argp-standalone/argp-standalone'
make: *** [Makefile:325: install-recursive] Error 1
cp: cannot stat 'libargp.a': No such file or directory

checking for argp_parse in -largp... no
### Error! argp must be installed first. Try 'brew install argp-standalone'.
make: *** No rule to make target 'check'.  Stop.