ahknight / httpsig Goto Github PK

The first usage example in the README does not work. It raises the following:
AttributeError: 'Signer' object has no attribute 'sign'

An sdist is the "lowest-common denominator" for the Python packaging ecosystem. It is more directly auditable against the sources than a none-any wheel, and is consumable in environnments where third-party binaries are not workable (e.g., see buildout/buildout#144 (comment)).

setup.py currently requires:

pycryptodome==3.4.7

see: https://github.com/ahknight/httpsig/blob/master/setup.py#L40

install_requires should not be used to pin dependencies to exact version. See: https://packaging.python.org/discussions/install-requires-vs-requirements/

It is not considered best practice to use install_requires to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades.

Unless there is a good reason which I am not aware of, something like:

install_requires=['pycryptodome>=3,<4', 'six']

should accept any pycryptodome version 3.x.x

Hello,

I'm using requests.py version 2.7.0 and when I use the HTTPSignatureAuth object, I'm getting the following exception:

File "/var/lib/python2.7/site-packages/requests/api.py", line 69, in get
    return request('get', url, params=params, **kwargs)
  File "/var/lib/python2.7/site-packages/requests/api.py", line 50, in request
    response = session.request(method=method, url=url, **kwargs)
  File "/var/lib/python2.7/site-packages/requests/sessions.py", line 451, in request
    prep = self.prepare_request(req)
  File "/var/lib/python2.7/site-packages/requests/sessions.py", line 382, in prepare_request
    hooks=merge_hooks(request.hooks, self.hooks),
  File "/var/lib/python2.7/site-packages/requests/models.py", line 308, in prepare
    self.prepare_auth(auth, url)
  File "/var/lib/python2.7/site-packages/requests/models.py", line 496, in prepare_auth
    r = auth(self)
  File "/var/lib/python2.7/site-packages/httpsig/requests_auth.py", line 35, in __call__
    path=r.path_url)
  File "/var/lib/python2.7/site-packages/httpsig/sign.py", line 100, in sign
    signable = generate_message(required_headers, headers, host, method, path)
  File "/var/lib/python2.7/site-packages/httpsig/utils.py", line 74, in generate_message
    raise Exception('missing required header "%s"' % (h))
Exception: missing required header "date"

It seems like I have everything installed correctly, do you know if I'm doing something wrong, or should I investigate further?

I might have found a bug. Unless I'm missunderstanding something.
If you try to merge an existing normal dict the result is None
Tested with Python 3.5.1 :

    import httpsig
    from email.utils import formatdate

    headers = {'whatever': 'the weather' }
    signed_headers_dict = hs.sign(
        {'Date': formatdate(timeval=None, localtime=False, usegmt=True), 'Host': '127.0.0.1:8000'},
        method='GET',
        path='/'
    )
    headers = headers.update(signed_headers_dict)
    print header # wil be None
    headers = signed_headers_dict.update(headers)
    print header # wil be None

The references are updated and the implemented standard is again superseded by httpbis.

You can track the current status of the draft here: https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/

The Funkwhale Collective might have funding available to make this lib comply to the draft again, please get in touch asap if you are interested

PyCrypto is dead, #pycrypto/pycrypto#238, and it won't work with Python 3.6 on Windows.

Perhaps httpsig should require pycryptodome instead of pycrypto. I created a fork with these changes and it seems to work fine so far with all tests passing.

At the moment there's no way to contact the project owner, ie. for responsible disclosure purposes, as a random example.

Some frameworks such as Python Requests do not seem to add a Date header automatically. If the header is missing but is required to sign the request, httpsign should add one automatically.

Draft 10 of the specification is now available. The README refer to draft 8, and the code need to be updated to work with the updated description.

hi! first off, thanks for maintaining and working on this library. we appreciate it!

i'm implementing a protocol (ActivityPub) and using HTTP Signatures via the Signature HTTP header, but httpsig currently only supports the Authorization header. any chance you could add Signature support?

as a proof of concept, i've done this in snarfed/httpsig@6f0ebfe. example usage in snarfed/bridgy-fed@b123088. it's definitely not the way you'd do it for real, but it does work.

thanks in advance!

Hi, I'm @msporny, primary author of the HTTP Signatures specification at IETF for many years now. You've implemented some variation of that specification.

I need your help to move that specification towards a global standard at IETF. Hearing from implementers, such as you, is a big part of determining if the work toward a global standard should proceed. The IETF HTTP Working Group is determining whether the work should proceed right now. This is very good news, because the European Banking API community, W3C DID Working Group, W3C Credentials Community Group and other standards setting organizations depend on implementations standardizing on a way to do HTTP Signatures.

The deadline for noting your support is Jan 31st 2020 (in ~10 days).

Here's where you can make a difference...

Here is the IETF HTTP WG Call for Adoption:

https://lists.w3.org/Archives/Public/ietf-http-wg/2020JanMar/0002.html

To note your support of the specification:

1. Go here and click "subscribe to this list": https://lists.w3.org/Archives/Public/ietf-http-wg/
2. Verify your subscription by checking your email and clicking on the link that is mailed to you.
3. Go here and click "respond to this message": https://lists.w3.org/Archives/Public/ietf-http-wg/2020JanMar/0002.html
4. Write an email stating:
   4.1 That you support the adoption of the draft.
   4.2 Why you support the adoption of the draft.
   4.3 How you plan to make use the specification, either directly, or indirectly (via someone else's software).
5. Set up an email filter to put all mail sent to [email protected] into its own folder. The mailing list averages ~350 emails/month. You can also leave the mailing list immediately after sending the email above if that amount of email traffic is unacceptable to you.

For an example of the type of email you could write, see this:

https://lists.w3.org/Archives/Public/ietf-http-wg/2020JanMar/0018.html

Thanks a ton for supporting the specification through your implementation. I hope you consider helping us take the specification across the goal line by voicing your support in the IETF HTTP Working Group!

Trying to use httpsig as install_requires in my setup.py but python setup.py install keeps failing with:

Could not find suitable distribution for Requirement.parse('httpsig')

Happens with both py2.7 and py3.4

Testing with:

from setuptools import setup

setup(
    name='test-httpsig',
    install_requires=[
        'httpsig'
    ]
)

pip install httpsig works fine though

HeaderSigner has a useful parameter called sign_header which allows to specify the header to add the signature to. It defaults to authorization but some services require Signature: .... Unfortunately this is not available for the Python requests, because HTTPSignatureAuth automatically initializes self.header_signer with the default value of authorization and it cannot be changed.

The IETF draft spec (ver 09) says:

       If the header field name is `(request-target)` then generate the
       header field value by concatenating the lowercased :method, an
       ASCII space, and the :path pseudo-headers (as specified in
       HTTP/2, Section 8.1.2.3 [6]).

This could be read to mean either that just the :method pseudo-header should be lower-cased or that both :method and :path should be lower-cased. The service that I'm working with definitely seems to expect both to be lower-cased.

Essentially, I think this line in utils.py:

            signable_list.append('%s: %s %s' % (h, method.lower(), path))

should be changed to:

            signable_list.append('%s: %s %s' % (h, method.lower(), path.lower()))

Hi. Just wanted to let you know I decided to upload httpsig into Debian. The source of the uploaded package is available from <URL: https://salsa.debian.org/pere/python-httpsig >. The debian/patches/ directory contain the changes I needed to apply to get it building and working in Debian.

Once the package is accepted into the Debian archive, its status can be seen from <URL: https://tracker.debian.org/pkg/python-httpsig >.

Is there anything I should know about this package related to packaging? Will its API be stable for the next 2-3 years, or should I keep it out of the stable Debian release?