Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

router+build: update to the latest version of lightning-onion #3027

Merged
merged 9 commits into from
May 3, 2019
Merged

router+build: update to the latest version of lightning-onion #3027

merged 9 commits into from
May 3, 2019

Commits on May 1, 2019

  1. build: update to latest lightning-onion version

    @Roasbeef
    Roasbeef committed May 1, 2019
    Configuration menu
    Copy the full SHA
    cba803b View commit details
    Browse the repository at this point in the history

  2. router: convert Route.ToHopPayloads() to Route.ToSphinxPath() 

    In this commit, we update the process that we use to generate a sphinx
packet to send our onion routed HTLC. Due to recent changes in the
`sphinx` package we use, we now need to use a new PaymentPath struct. As
a result, it no longer makes sense to split up the nodes in a route and
their per hop paylods as they're now in the same struct. All tests have
been updated accordingly.
    @Roasbeef
    Roasbeef committed May 1, 2019
    Configuration menu
    Copy the full SHA
    bab9573 View commit details
    Browse the repository at this point in the history

  3. lnwire: export failureMessageLength constant

    @Roasbeef
    Roasbeef committed May 1, 2019
    Configuration menu
    Copy the full SHA
    558c8ca View commit details
    Browse the repository at this point in the history

  4. htlcswitch: for UpdateFailMalformedHTLC packets mark fail as needing … 

    …conversion

In this commit, we start the first phase of fixing an existing bug
within the switch. As is, we don't properly convert
`UpdateFailMalformedHTLC` to regular `UpdateFailHTLC` messages that are
fully encrypted. When we receive a `UpdateFailMalformedHTLC` today,
we'll convert it into a regular fail message by simply encoding the
failure message raw. This failure message doesn't have  a MAC yet, so if
we sent it backwards, then the destination wouldn't be able to decrypt
it. We can recognize this type of failure as it'll be the same size as
the raw failure message max size, but it has 4 extra bytes for the
encoding. When we come across this message, we'll mark is as needing
conversion so the switch can take care of it.
    @Roasbeef
    Roasbeef committed May 1, 2019
    Configuration menu
    Copy the full SHA
    649e080 View commit details
    Browse the repository at this point in the history

  5. htlcswitch: add new EncryptMalformedError method to ErrorEncrypter 

    In this commit, we add a new method to the ErrorEncrypter interface:
`EncryptMalformedError`. This takes a raw error (no encryption or MAC),
and encrypts it as if we were the originator of this error. This will be
used by the switch to convert malformed fail errors to regular fully
encrypted errors.
    @Roasbeef
    Roasbeef committed May 1, 2019
    Configuration menu
    Copy the full SHA
    c67ca0a View commit details
    Browse the repository at this point in the history

  6. htlcswitch: properly handle direct link malformed HTLC failures 

    In this commit, we fix a bug that caused us to be unable to properly
handle malformed HTLC failures from our direct link. Before this commit,
we would attempt to decrypt it and fail since it wasn't well formed. In
this commit, if its an error for a local payment, and it needed to be
converted, then we'll decode it w/o decrypting since it's already
plaintext.
    @Roasbeef
    Roasbeef committed May 1, 2019
    Configuration menu
    Copy the full SHA
    cdc4aca View commit details
    Browse the repository at this point in the history

  7. htlcswitch: properly convert multi-hop malformed HTLC failures 

    In this commit, we now properly convert multi-hop malformed HTLC
failures. Before this commit, we wouldn't properly add a layer of
encryption to these errors meaning that the destination would fail to
decrypt the error as it was actually plaintext.

To remedy this, we'll now check if we need to convert an error, and if
so we'll encrypt it as if it we were the source of the error (the true
source is our direct channel peer).
    @Roasbeef
    Roasbeef committed May 1, 2019
    Configuration menu
    Copy the full SHA
    be63c7d View commit details
    Browse the repository at this point in the history

  8. htlcswitch: add new TestUpdateFailMalformedHTLCErrorConversion test 

    In this commit, we add a new test to ensure that we're able to properly
convert malformed HTLC errors that are sourced from multiple hops away,
or our direct channel peers. In order to test this effectively, we force
the onion decryptors of various peers to always fail which will trigger
the malformed HTLC logic.
    @Roasbeef
    Roasbeef committed May 1, 2019
    Configuration menu
    Copy the full SHA
    56c969c View commit details
    Browse the repository at this point in the history

  9. test: update itest to no longer expect incorrect message for sphinx r… 

    …eplay test

In this commit, we update the itests to expect the correct message for
the sphinx replay test. Before the fixes in the prior commits, we
expected the wrong error since we were actually unable to decrypt these
converted malformed HTLC errors. Now, we'll properly return a parse able
error, so we assert against that error instead of the failure to decode
an error.
    @Roasbeef
    Roasbeef committed May 1, 2019
    Configuration menu
    Copy the full SHA
    2f2a907 View commit details
    Browse the repository at this point in the history