Secnet progress [and 2 more messages]

[Ian Jackson]

Mark Wooding writes ("Re: Secnet progress"):
> I totally intended to go back over your previous comments.  And, indeed,
> I have now done this!  Yay!

Thanks!  All SGTM.  Replying just to the bits that need it:

>   * [PATCH 24/43], [PATCH 25/43] is about the code dump from Catacomb.
>     I'm now planning to do that in a mostly automated manner, which
>     hopefully will address all of your concerns.
> 
>     Hmm.  My new script doesn't currently report a URL for the donor
>     repository.  I'm not sure how it would guess one.  I could hardcode
>     one, but that doesn't seem very useful.

You could hardcode the url and use git-ls-remote to check that it is
actually true.  (git-request-pull does this already so there is
precedent.)

It occurred to me to wonder whether making a git merge commit would be
appropriate.

>     site: Replace remote's caps after verifying MSG3

Will review this separately.

> >  * "magic.h: Present message labels as an encoding of major
> >     and minor numbers."
> >    The motivation for this commit is not presented.  This is not
> >    really ideal for review of a complex new idea as part of a "spring
> >    clean" series.  I nearly decided to drop this patch from my push
> >    for this reason but ultimately I chose to take it on faith.
> 
> Fair point.  The patch was motivated by the introduction (in the
> `mdw/xdh' series) of `MSG3TER', which is kind of like `MSG3BIS' but with
> even more things in it.  If I just left the current ad-hoc message-code
> dispatch machinery in `site.c' unchanged, I'd end up with several
> ever-growing lists of MSG3-like message codes.  My thought was that
> making the message-code more structured would let that structure shine
> through into the dispatch code.
>
> Hmm.  This probably makes more sense with the `Prepare for adding more
> MSG3 variants' patch, which I neglected to contribute.  That change
> applied cleanly onto mdw/springclean.

I will look at this in a moment but I wonder if a simple
  #define case_MSG3X case MSG3: case MSG3BIS: case MSG3TER:
would have done...

> See also
>   https://www.chiark.greenend.org.uk/pipermail/sgo-software-discuss/2017/000483.html
> and subsequent discussion.

Ah nice to now that I produce the same answer given the same input
:-).  Your point about unpick in that mail thread makes sense.

... just went and looked at
   site: Prepare for adding more MSG3 variants
and that makes sense of it all.

OK.  Thanks.

> >  * "secnet-wireshark.lua: Add a Wireshark dissector."
> >    Should something install this somewhere ?
> 
> Probably.  But it turns out that this is /really hard/, and breaks all
> the time.  My cut at the necessary Autoconf machinery is
>   https://git.distorted.org.uk/~mdw/tripe/blob/HEAD:/configure.ac#l218

OMG.  This is hideous.  Can't we just hardcode it in our Makefile.in ?

> Alternatively, an individual user can copy or link the thing into
> ~/.local/lib/wireshark/plugins/ (yes!  I didn't previously know that
> ~/.local/lib/ was a thing), but that's not something that a build script
> should be doing.

Indeed.

> >  * This list is in addition to the changes I made myself in
> >    5d903ef..ce32dd8, which I'd appreciate it if you looked at.
> 
> Err, upstream doesn't seem to have moved.  What's going on?  Oh!  It's
> in `Ian's personal secret secnet repo'.

Oops, sorry, fixed.

>   * gitignore: Ah!  Fair point.  I expect that I'll produce more of
>     these as time goes on.  Consider it the downside of me testing that
>     your out-of-tree build machinery works. :-)

FE :-).

> > > `mdw/xdh' contains the rest of my XDH work, and is where I'm currently
> > > working.  It starts by refactoring the DH closure interface, then moves
> > > onto DH group negotiation, and then adds Bernstein's X25519 and X448.
> >
> > I have not looked at this at all for the reason I give above.  Please
> > let me know whether you think I should review it all de novo, or go
> > back to my mails from before, or wait, or what.
> 
> Sure.  I think it's probably best if I try to get a tidied up version
> ready for you before sunrise on Sunday.

Absolutely no hurry.

Mark Wooding writes ("Re: Secnet progress"):
> Less discussed than I hoped :-/.  Oops.  Let me try again.
...
> None of these options really appeals. :-/

Mark Wooding writes ("Re: Secnet progress"):
> Oh, never mind.  It seems that you had exactly the same difficulty with
> the RSA work, so I should take the same approach, which is ugly but
> easy.

The unpick call doesn't have to do the whole parsing job, just find
the length.  That may be easier.  The actual parsing can be deferred.

Also if you want to make the struct alg_msg_data have a couple of
spare fields or be a union or something, that would be fine by me.  We
can afford to put another pointer or three in it and making it a union
is simple even if it's a slight layer violation.

Ian.

-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.