GithubHelp home page GithubHelp logo

rescrv / libmacaroons Goto Github PK

View Code? Open in Web Editor NEW
491.0 23.0 47.0 249 KB

Macaroons are flexible authorization credentials that support decentralized delegation, attenuation, and verification.

License: BSD 3-Clause "New" or "Revised" License

C 67.40% Go 9.17% Python 5.33% C++ 1.95% Shell 2.08% Makefile 3.07% M4 11.00%

libmacaroons's Issues

third party caveats produce invalid JSON when serialized

It seems that the vid field in third party caveats is not correctly encoded, which leads to an exception when trying to serialize macaroons in JSON format.

>>> m = macaroons.create("my location", "my secret key", "my identifier")
>>> m = m.add_third_party_caveat("tp location", "tp root key", "tp caveat")
>>> m.serialize(format='json')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "bindings/python/macaroons.pyx", line 181, in macaroons.Macaroon.serialize (bindings/python/macaroons.c:2259)
    return bytes(data[:data_sz]).decode('utf8')
UnicodeDecodeError: 'utf8' codec can't decode byte 0x9c in position 90: invalid start byte

I added a print statement before the exception was raised, and it printed this:

('got serialized data', '{"v":2,"l":"my location","i":"my identifier","c":[{"i":"tp caveat","l":"tp location","v":"\x9cJ\xb4jr\x11\xa5\x13\x8e\xba\x13\xe2y\xb4\x829n\x96\x0c1b\x9e\x13\xff\x8a\x89\x10B\xe2\xff+\xf7hh\xe3W\xef\xd3SO\xe0i\x062\xcf\x93\xb1\xc3\xd8r\xa1\xf5\xb5m\\g\xad\xf1\x96\xa4\x164U\xde\t\xb0\x89\x15\xb7\x12"}],"s64":"FodXLpedS2YbvCiUOqNbArA2Edw4Plc7SBFPNHc9gBI"}')

It looks like the vid field should have been base64 encoded and then the v64 field used.

python bindings: produce better error when format not recognized

When we pass an unknown format to macaroon.serialize, it produces this error:

>>> m.serialize(format='json1')
Exception KeyError: ('json1',) in 'macaroons.Macaroon.version' ignored
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "bindings/python/macaroons.pyx", line 179, in macaroons.Macaroon.serialize (bindings/python/macaroons.c:2215)
    if self.is_json(format):
  File "bindings/python/macaroons.pyx", line 289, in macaroons.Macaroon.is_json (bindings/python/macaroons.c:3914)
    '1': False}[v]
KeyError: 'json1'

It would be nice if it made it clearer what the error signifies (for example by raising an exception which mentions that it's an unknown format, possibly stating the possible format values, as there is no documentation for that, AFAICS)

Seemingly contradictory readme

Sorry if this is a really silly issue but the following two seemingly paradoxical paragraphs are killing me.

Both:

More importantly, the verifier will also work for macaroons we've not yet seen,
like one that only permits Alice to deposit into her account:

>>> N = M.add_first_party_caveat('action = deposit')
>>> V.verify(N, secret)
True

and

Equally important is the verifier's ability to reject improper macaroons because
they are not authorized. An improper macaroon could have additional caveats not
known to the verifier, or have false general caveats. Worse, an unauthorized
macaroon could be an attempt by a determined attacker to break into our bank.
The verifier we've built will reject all of these scenarios:

>>> # Unknown caveat
>>> N = M.add_first_party_caveat('OS = Windows XP')
>>> V.verify(N, secret)
Traceback (most recent call last):
Unauthorized: macaroon not authorized

(emphasis mine)

cannot be true. It cannot be true that we can add a caveat that the verifier doesn't know about, and have it both succeed and fail, and indeed if you add a caveat like action = deposit to the macaroon and try to use the verifier without updating it, verfication fails.

What am I missing?

binary serialization format could be improved

  • fields are limited to ~64K bytes. Although web cookies
    are limited to 4K, macaroons may have much wider
    use, and fields can grow large when arbitrary info
    is encoded into third party caveat ids.
  • caveat boundaries are not well defined. This
    makes it hard to tell where the last caveat ends,
    and therefore hard to add a new field to either
    caveats or the macaroon itself, which limits
    the scope of potential future backwardly compatible
    format changes.

All that said though, I do appreciate the simplicity,
ASCII-visibility and efficiency of the current format.
Most possible format changes would compromise
on at least one of the above qualities to some degree.

I'm raising this issue because I think the subject
should be at least discussed.

Proposal: signature in serialized macaroon as hex-string (hexlyfied)

Hi,

in the readme.md of libmacaroon, there is an example of a Base64 serialized macaroon (look for "M.serialize()").
When decoding this Base64 string everything is human readable, except the signature.
The signature is 32 bytes, which may contain everything, from white spaces to Greek letters.

My team and I plan to adopt macaroons for our growing microservice application landscape. As written in the research paper, there are a lot of benefits, which are very attractive for us.
BUT, when implementing, debugging and tracing macaroons based requests, we prefer to see human readable plain text only. It makes their handling easier. (IMHO, Base64 is transparent, I want to inspect macaroons)

So, I propose to change the signature and 'vid' packets to be packed as hex strings (e.g. cafebabe42),
which encourages better human readability.

What do you think?

PS: You may copy&paste the Base64 example to www.base64decode.org and see for yourself.

pyx function signature error

Apologies, I haven't dug into this so I don't know if this is a trivial fix or not. I get this error when trying to build:

vagrant@wesdev:~/libmacaroons$ make
make --no-print-directory all-am
  PYX    bindings/python/macaroons.c

Error compiling Cython file:
------------------------------------------------------------
...
        MACAROON_NOT_AUTHORIZED   = 2055
        MACAROON_NO_JSON_SUPPORT  = 2056

    macaroon* macaroon_create(unsigned char* location, size_t location_sz, unsigned char* key, size_t key_sz, unsigned char* id, size_t id_sz, macaroon_returncode* err)
    void macaroon_destroy(macaroon* M)
    int macaroon_validate(const macaroon* M)
                                       ^
------------------------------------------------------------

bindings/python/macaroons.pyx:55:40: Expected ')', found '*'
make[1]: *** [bindings/python/macaroons.c] Error 1
make: *** [all] Error 2

Am I missing something?

how does it work?

But handling things this way completely
sidesteps all the crypto-goodness that macaroons are built upon.

what is this crypto-goodness? I see hmac and secretbox in the code, but how it is actually applied to the caveats is not obvious (from glancing at the code)

my guess something like you hmac the secret, then hmac each caveat in turn (which would mean you could never remove a caveat but you could add one)? Is this the correct basic idea? is there any documentation about how it works?

Cant Build from source

gets this issue when i try to import

import macaroons
Traceback (most recent call last):
File "", line 1, in
ImportError: libmacaroons.so.0: cannot open shared object file: No such file or directory

first party caveats are not always checked by verifier

As far as I can tell, the following script should print:

 checked conditions: ['splendid', 'wonderful', 'top of the world']

but it actually prints:

checked conditions: ['top of the world', 'wonderful']

One first party caveat does not appear to be checked.

import macaroons
m1 = macaroons.create("", "root-key", "root-id")
m1 = m1.add_first_party_caveat("wonderful")
m1 = m1.add_third_party_caveat("bob", "bob-caveat-root-key", "bob-is-great")

m2 = macaroons.create("bob", "bob-caveat-root-key", "bob-is-great")
m2 = m2.add_first_party_caveat("splendid")

m3 = macaroons.create("bob", "bob-caveat-root-key", "bob-is-great")
m3 = m3.add_first_party_caveat("top of the world")

m2 = m1.prepare_for_request(m2)
m3 = m1.prepare_for_request(m3)
checked = []
def check(cond):
	checked.append(cond)
	return True
v = macaroons.Verifier()
v.satisfy_general(check)
v.verify(m1, "root-key", [m2, m3])
checked.sort()
print('checked conditions: {}'.format(checked))

Can't install on ubuntu and for python 3

I'm trying to install libmacaroons on ubuntu trusty.

Dependencies:

apt-get install -y make wget tar autoconf libtool pkg-config
apt-get install -y python3 python3-dev python3-software-properties build-essential
pip3 install cython

Sodium:

wget https://github.com/jedisct1/libsodium/releases/download/0.6.1/libsodium-0.6.1.tar.gz
tar xzvf libsodium-0.6.1.tar.gz
cd libsodium-0.6.1 && ./configure && make && make check && sudo make install

Macaroons:

wget -O libmacaroons.tar.gz https://github.com/rescrv/libmacaroons/archive/master.tar.gz
tar xzvf libmacaroons.tar.gz
cd libmacaroons-master && autoreconf -i && ./configure --enable-python-bindings && make && sudo make install

I get the following error when running make though:

/usr/bin/ld:bindings/python/.libs/macaroons.ver:2: syntax error in VERSION script
collect2: error: ld returned 1 exit status
make[1]: *** [bindings/python/macaroons.la] Error 1
make: *** [all] Error 2

Any thoughts? Thanks!

Use "developer-safe" API in Python bindings

First of all, great initiative! :)

That said, the Python bindings have an "unsafe" API that makes it too easy to use the library in an incorrect and hence insecure way. The signature of the verify() API returns a boolean result, which makes code like this seem correct but insecure:

m.verify()
do_something_assuming_it_is_verified()

The approach cryptography (the python project) takes avoid these kind of problems (see e.g. http://cryptography.readthedocs.org/en/latest/hazmat/primitives/mac/hmac/) by raising appropriate exceptions instead. In that case, code like the above would be secure, and code that needs to handle the verification error must do so explicitly:

try:
    m.verify()
except macaroon.VerificationError:
    pass  # do something sensible here

pkg-config is required

Hi all,

I am trying to install libmacaroons in my local machine (Mac OS Catalina), but I am having issues, due to an error telling me that pkg-config is not found. Don't know what is happening but I have already installed all the requirements for this library as you can check below:

 ~ autoconf --version
autoconf (GNU Autoconf) 2.71
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
<https://gnu.org/licenses/gpl.html>, <https://gnu.org/licenses/exceptions.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.
➜  ~ automake --version
automake (GNU automake) 1.16.4
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later <https://gnu.org/licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Tom Tromey <[email protected]>
       and Alexandre Duret-Lutz <[email protected]>.
 ➜  ~ glibtool --version
glibtool (GNU libtool) 2.4.6
Written by Gordon Matzigkeit, 1996

Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
➜  ~ pkg-config --version
0.29

And here below, the outputs I get when I trying to install libmacaroons. Thinking the problem is related to the m4 macros that for some reason the installation script is not able to find in my computer. Any suggestion to solve this issue?

  ~ git clone https://github.com/rescrv/libmacaroons.git
Cloning into 'libmacaroons'...
remote: Enumerating objects: 615, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 615 (delta 1), reused 0 (delta 0), pack-reused 610
Receiving objects: 100% (615/615), 248.70 KiB | 684.00 KiB/s, done.
Resolving deltas: 100% (362/362), done.
➜  ~ cd  libmacaroons 
➜  libmacaroons git:(master) autoreconf -i                                       
glibtoolize: putting auxiliary files in '.'.
glibtoolize: copying file './ltmain.sh'
glibtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
glibtoolize: copying file 'm4/libtool.m4'
glibtoolize: copying file 'm4/ltoptions.m4'
glibtoolize: copying file 'm4/ltsugar.m4'
glibtoolize: copying file 'm4/ltversion.m4'
glibtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:69: warning: The macro `AC_PYTHON_DEVEL' is obsolete.
configure.ac:69: You should run autoupdate.
m4/ax_python_devel.m4:72: AC_PYTHON_DEVEL is expanded from...
configure.ac:69: the top level
configure.ac:16: installing './compile'
configure.ac:16: installing './config.guess'
configure.ac:16: installing './config.sub'
configure.ac:12: installing './install-sh'
configure.ac:12: installing './missing'
Makefile.am: installing './depcomp'
➜  libmacaroons git:(master) autoupdate
➜  libmacaroons git:(master) ✗ autoreconf -i
➜  libmacaroons git:(master) ✗ ./configure --enable-python-bindings                
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking for a Python interpreter with version >= 2.6... python
checking for python... /usr/bin/python
checking for python version... 2.7
checking for python prefix... /System/Library/Frameworks/Python.framework/Versions/2.7
checking for python exec_prefix... /System/Library/Frameworks/Python.framework/Versions/2.7
checking for python platform... darwin
checking for python script directory... /Library/Python/2.7/site-packages
checking for python extension module directory... /Library/Python/2.7/site-packages
checking build system type... x86_64-apple-darwin19.6.0
checking host system type... x86_64-apple-darwin19.6.0
checking how to print strings... printf
checking whether make supports the include directive... yes (GNU style)
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
checking if the linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 196608
checking how to convert x86_64-apple-darwin19.6.0 file names to x86_64-apple-darwin19.6.0 format... func_convert_file_noop
checking how to convert x86_64-apple-darwin19.6.0 file names to toolchain format... func_convert_file_noop
checking for /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... no
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking for dsymutil... dsymutil
checking for nmedit... nmedit
checking for lipo... lipo
checking for otool... otool
checking for otool64... no
checking for -single_module linker flag... yes
checking for -exported_symbols_list linker flag... yes
checking for -force_load linker flag... yes
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking for gcc option to produce PIC... -fno-common -DPIC
checking if gcc PIC flag -fno-common -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin19.6.0 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for gcc... (cached) gcc
checking whether the compiler supports GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to enable C11 features... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) gcc3
checking for g++... g++
checking whether the compiler supports GNU C++... yes
checking whether g++ accepts -g... yes
checking for g++ option to enable C++11 features... none needed
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
checking if the linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) is GNU ld... no
checking whether the g++ linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) supports shared libraries... yes
checking for g++ option to produce PIC... -fno-common -DPIC
checking if g++ PIC flag -fno-common -DPIC works... yes
checking if g++ static flag -static works... no
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin19.6.0 dyld
checking how to hardcode library paths into programs... immediate
checking pkg-config m4 macros... no
configure: error: 
pkg-config is required.
See pkg-config.freedesktop.org

Proposal: using URL and filename safe base64 encoder for serializing macaroons

Hi,

the current serialization format of macaroons uses Base64, as described in RFC 1521.
When using macaroons as bearer tokens in HTTP requests (e.g. query params)
this may cause problems, because Base64 uses characters like + and / for encoding.

There is an alternative: RFC 4648 (Oct.2006),
which describes Base 64 Encoding with URL and filename safe alphabet.
The changes in encoding are minimal: two alphabet characters changed and no padding is applied.
See also:
https://tools.ietf.org/html/rfc4648#section-5

What do you think about changing the serialization to base64url (the preferred name, as stated in the RFC).

Regards
Martin

ANAL_WARNINGS command not found

I keep getting this error on my during ./configure

./configure: line 16287: ANAL_WARNINGS: command not found
./configure: line 16290: syntax error near unexpected token `SODIUM,'
./configure: line 16290: `PKG_CHECK_MODULES(SODIUM, libsodium >= 0.4)'

I've installed libsodium from here: https://download.libsodium.org/libsodium/releases/

Happens on my ubuntu machine (x86_64)

Potential undersized buffer

In macaroon_add_third_party_caveat_raw(...), I'm wondering if the buffer for enc_cyphertext should be the same size as that for enc_plaintext?

libmacaroons/macaroons.c

Lines 342 to 352 in fb878b9

MACAROON_API struct macaroon*
macaroon_add_third_party_caveat_raw(const struct macaroon* N,
const unsigned char* location, size_t location_sz,
const unsigned char* key, size_t key_sz,
const unsigned char* id, size_t id_sz,
enum macaroon_returncode* err)
{
unsigned char new_sig[MACAROON_HASH_BYTES];
unsigned char enc_nonce[MACAROON_SECRET_NONCE_BYTES];
unsigned char enc_plaintext[MACAROON_SECRET_TEXT_ZERO_BYTES + MACAROON_HASH_BYTES];
unsigned char enc_ciphertext[MACAROON_SECRET_BOX_ZERO_BYTES + MACAROON_HASH_BYTES];

The call to macaroon_secretbox(...) appears to be attempting to store data beyond the end of enc_cyphertext when SECRET_BOX_OVERHEAD is not included when initialising the buffer size.

libmacaroons/macaroons.c

Lines 384 to 390 in fb878b9

/* now encrypt the key to give us vid */
memmove(enc_plaintext + MACAROON_SECRET_TEXT_ZERO_BYTES, key,
key_sz < MACAROON_HASH_BYTES ? key_sz : MACAROON_HASH_BYTES);
if (macaroon_secretbox(N->signature.data, enc_nonce, enc_plaintext,
MACAROON_SECRET_TEXT_ZERO_BYTES + MACAROON_HASH_BYTES,
enc_ciphertext) < 0)

In macaroon_verify_inner_3rd(...), enc_cyphertext buffer size matches enc_plaintext:

libmacaroons/macaroons.c

Lines 717 to 730 in fb878b9

static int
macaroon_verify_inner_3rd(const struct macaroon_verifier* V,
const struct caveat* C,
const unsigned char* sig,
const struct macaroon* TM,
struct macaroon** MS, size_t MS_sz,
enum macaroon_returncode* err,
size_t* tree, size_t tree_idx)
{
unsigned char enc_key[MACAROON_SECRET_KEY_BYTES];
const unsigned char *enc_nonce;
unsigned char enc_plaintext[MACAROON_SECRET_TEXT_ZERO_BYTES + MACAROON_HASH_BYTES];
unsigned char enc_ciphertext[MACAROON_SECRET_BOX_ZERO_BYTES + MACAROON_HASH_BYTES + SECRET_BOX_OVERHEAD];
unsigned char vid_data[VID_NONCE_KEY_SZ];

Note: SECRET_BOX_OVERHEAD is defined as the difference between MACAROON_SECRET_TEXT_ZERO_BYTES and MACAROON_SECRET_BOX_ZERO_BYTES.

libmacaroons/macaroons.c

Lines 329 to 331 in fb878b9

#define SECRET_BOX_OVERHEAD \
(MACAROON_SECRET_TEXT_ZERO_BYTES \
- MACAROON_SECRET_BOX_ZERO_BYTES)

Add pip installation instructions to the README

The most common way to install Python packages is via pip, a package manager.

The README explains how to compile Python bindings, but it would be helpful if it explained how to install via pip, or what stanza I need to add to setup.py or requirements.txt in order to install this library.

Thanks!

serialization produces invalid base64

The base64 does not have the required padding characters to
allow it to be parsed by standard base64 decoders.

Verify by taking some serialization from the example README.md:

echo 'MDAxY2xvY2F0aW9uIGh0dHA6Ly9teWJhbmsvCjAwMjZpZGVudGlmaWVyIHdlIHVzZWQgb3VyIHNlY3JldCBrZXkKMDAyZnNpZ25hdHVyZSDj2eApCFJsTAA5rhURQRXZf91ovyujebNCqvD2F9BVLwo' | base64 -d

produces an error.

macaroon_hash2 has unexpected implementation

To hash two items together with a key, I would expect the algorithm
to be hmac(key, item1 + item2). This is the algorithm used in the
macaroons paper in addCaveatHelper (MAC(sig, vId + cId)).

Instead, macaroon_hash2 uses hmac(key, hmac(key, item1) + hmac(key, item2)).

This is unexpected, and probably less efficient than the simpler approach.

Version 0.4.0 roadmap?

Hi,

Are there any plans for a v0.4.0?

I have an application that I'm working on which will start to depend on libmacaroons. I've noticed a few API breaks between current master and the latest tag -- will these be present in future released versions?

Additionally, I plan to package libmacaroons for Fedora/EPEL. Any upstream objections to that?

Thanks,

Brian

syntax error in VERSION script

Getting the following error when trying to build the python bindings using python 3.6:

/usr/bin/ld:bindings/python/.libs/macaroons.ver:2: syntax error in VERSION script

Said file contains the following:

{ global:
local: *; };

Same issue as #16 that was closed without actually being addressed.

Cookies are different from session IDs

Hi Robert,

I just discovered your project and it's really interesting 😄

I'm just a little bugged with the cookies comparison in the project description. I know I'm being a bit picky but cookies are just a key/value transport mean with a promise that a browser will send them back. They can be used to transport anything and even if we often use them to transport session IDs they cannot be compared IMO. It's the same when people compare JWT with cookies, you can transport JWT in a cookie.

I think it would be better to oppose macaroons with session IDs or maybe I haven't catched well the behaviour of macaroons yet.

WDYT?

Change usage of ``assert``

The assert macro is used to check certain conditions, including that the calling application is behaving as intended by passing in proper input. Any application-triggerable assert calls should be turned into failures that return the error.

No installation documentation + Linux installation problems

There seems to be nothing in the repository that documents how
to build the libmacaroons library.

I got as far as:

autoconf
./configure
make

At this point, we get this error:

make --no-print-directory all-am
  CC       base64.lo
  CC       macaroons.lo
macaroons.c:48:2: error: #error portability problem
 #error portability problem
  ^
make[1]: *** [macaroons.lo] Error 1
make: *** [all] Error 2

because libbsd (which doesn't exist on Linux) is required.
It seems that this is to get the arc4random_buf function,
which doesn't exist in Linux. How about using getrandom instead in Linux? ... except that getrandom
doesn't appear to exist in Ubuntu 14.04 which I'm using. Perhaps
the only decent solution is to open /dev/urandom directly.

If that include is deleted, we then get a bunch of errors like this:

port.c: In function 'macaroon_bin2hex':
port.c:130:5: error: 'for' loop initial declarations are only allowed in C99 mode
     for (size_t i = 0; i < bin_sz; ++i)
     ^
port.c:130:5: note: use option -std=c99 or -std=gnu99 to compile your code
make[1]: *** [port.lo] Error 1
make: *** [all] Error 2

because declaring variables inside for loops isn't pre-C99 standard C.
Having fixed that, it finally compiles (but really it shouldn't because
there's no definition of arc4random_buf available - if the declaration in
port.c was removed, then at least the compile should fail correctly,
but it doesn't because somehow the warnings for use of undeclared functions
seem to be disabled).

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.