IrcMeetings: irclog_2023-08-16.txt

plaisthos> topic for next meeting: Mark 2.5.x as old stable on https://community.openvpn.net/openvpn/wiki/SupportedVersions
<plaisthos> I might not make it to today's meeting
* uddr (~uddr@185.17.127.225) has joined
<MaxF> syzzer didn't expect you here!
<djpig> dazo also explained the copr process to me, so I can now release new versions there. He also added me as a maintainer to the Fedora package so that I can submit new versions there
<djpig> So we made good progress on spreading knowledge about release process around a bit
<djpig> don't think there is anything more to discuss about that?
<dazo> Now it's just to get you into the fedpkg tooling once the final access is configured and you can replace me :P
<djpig> Next topic: Tunnelcrack. Anything to discuss about that?
<dazo> What can we do about Tunnelcrack short term and long term?  And what has been decided so far?
<djpig> So novaflash had worked on preparing a statement about it at https://cryptpad.fr/pad/#/2/pad/edit/TWa9QJYxSQLjllhUfstlb13T/
<vpnHelper`> Title: CryptPad (at cryptpad.fr)
<rob0> I wrote a reply which has gone to some support customers / users. I think it has had mixed reviews so far.
<djpig> But not sure whether any of that was ever used.
<dazo> ahh, right
<djpig> So far I'm not aware of anyone actually working on possible mitigations
<dazo> okay, I don't think there's much more we can do right now.  It's a hard nut to crack, doing it properly and correctly.
<rob0> yes
<djpig> definitely a topic to discuss at the Hackathon
<dazo> I would suggest this being a reasonable topic for the hackathon
<dazo> heh
<djpig> okay, let's move on
<MaxF> for now, what are the mitigations for the local net attack? block-local, anything more?
<djpig> not sure whether anyone of the people that have looked into it is actually here today :/
<d12fk> we could just allow private network ranges, maybe with an opt-out (not sure where this would be needed)
<dazo> yeah, essentially ... you might be able to tweak it even harder with some firewalling too, though - and/or probably also policy based routing.  And that's what makes this hard to solve.
<d12fk> this would still allow th eprivate ranges from the other end of the tunnel to be re-routed though
<dazo> yupp
<djpig> in general I think this here is probably the worst channel to discuss that ;) Now that the issue is public, it could be discussed on the openvpn-devel mailing list, though
<dazo> +1
<djpig> okay, let's move on now
<djpig> dazo: TOB-OVPN-14 related patch has been merged, so I can mark this item as resolved, right?
<djpig> next topic on the list is Hackathon. Anything to discuss about that?
<dazo> djpig: Yepp!
<dazo> I have told ToB they can go ahead and audit all our changes in 2.6; that's an extra audit which was part of the initial contract with them.
<dazo> They have received a list of all issues we've resolved and pointed at our git commits
<dazo> But to be honest, none of these fixes are any big deals.  It's mostly minor things - and lots of it circling around NTLM authentication
<dazo> I think it's reasonable to consider if we generally want or need to support NTLM authentication at all.
<djpig> what does "changes in 2.6" mean, exactly? Can you please express that in a git log compatible ref expression? :)
<djpig> v2.6.0..v2.6.6 ?
<d12fk> IMHO NTLM is not better or worse than Basic-Auth, it just makes Proxies work for ppl
<dazo> hehe .... so each ToB-OVPN issue has been listed and points at specific git commits per fix
* becm has quit (Ping timeout: 252 seconds)
<djpig> ah, right. So they're auditing our changes for the issues they raised in the audit?
<dazo> Yeah, but how relevant is NTLM in todays enterprise world compared to basic auth?
<dazo> djpig: correct!
* MaxF has quit (Quit: Client closed)
<d12fk> dazo: still present
<dazo> ntlm - is there any enterprise infrastructure which can't do basic auth and requires ntlm?
* MaxF (~MaxF@cust-95-128-91-242.breedbanddelft.nl) has joined
<djpig> maybe we can disable it in the default build in 2.7.0 and see how many people complain?
<d12fk> I think admins want the slightly higher protection of credentials when they use NTLM over Basic
<djpig> hehe, any protection is slightly higher than "none"
<d12fk> hey, it's base64 encrypted =)
<dazo> :-P
<djpig> so this probably more an argument in the direction of "don't use insecure stuff even if you don't care because then someone might use it even though he cares but doesn't understand the implications". Or some such
<dazo> I think it would be a good idea to disable NTLM support in 2.7 by default.  That's a good way to flush out if there are use cases for it.  Reverting that would be a easy enough, even mid-release if there are enough users demanding it
<djpig> okay, I will make a not in the meeting notes and add it to https://community.openvpn.net/openvpn/wiki/DeprecatedOptions
<djpig> we can discuss it then further in any 2.7 plan discussion. E.g. during hackathon
<djpig> while we're on the topic of deprecation. plaisthos raised this item: Mark 2.5.x as old stable on https://community.openvpn.net/openvpn/wiki/SupportedVersions
<djpig> anyone any issues with me just doing that?
<djpig> seems not
<rob0> it looks appropriate according to what's on that page already
<djpig> yeah
<djpig> also noone has raised any topics regarding Hackathon. So let's see what else there is
<plaisthos> hey, I just arrived
<rob0> wb
<djpig> right "License amendment". We need to find volunteers that deep dive into the last few submissions we did not receive permission to relicense. And a separate set of people that then reimplement those changes without having seen the original changes recently. So we can at least claim some "clean-room" separation
<MaxF> I'm volunteering for mbedtls related stuff
<MaxF> but how can you rewrite the code without looking at it?
<plaisthos> in some cases, get a tree from someone else with that feature reverted/removed and a description what the feature should do
<plaisthos> and then implement it
<djpig> the person looking at it needs to document the feature/change
<djpig> since I have no aspirations implementing anything, I can try to start looking at the original changes.
<djpig> if anyone else wants to take a stab at it let me know so we don't start with the same change
<dazo> MaxF: clean-room implementations are done by two persons.  One looks at the solution and describes them as a functional description (not giving hints about how to implement it in detail).  The second one reads the spec and implements it without any knowledge of the existing implementation.
<plaisthos> so the james bottemley we just revert 
<djpig> yeah "without knowledge" is probably hard in our community. But we should at least try
<plaisthos> it is just a an OpenSSL 1.x feature and if he wants it in, he can agree to the license change
<plaisthos> - J�r�mie Courr�ges-Anglas <jca@wxcvbn.org> 
* d12fk has no knowledge
<plaisthos> that is the OpenBSD guy. Will have to contact him again to see if he agrees when we promoised to keep the old license 
<plaisthos> - Andris Kalnozols <andris@hpl.hp.com>
<djpig> okay, so I should start with Andris' changes?
<plaisthos> just looking for a git commend to show me the one line summary from a certain email
* becm (~Thunderbi@rtr.astos.de) has joined
<plaisthos> ed5a400e1 extract_x509_extension(): hide status message during normal operation.
<plaisthos> f4e0ad82b Do not upcase x509-username-field for mixed-case arguments.
<plaisthos> b443772bb Fix some typos in the man page.
<plaisthos> probably someone neeeds to look at that
<dazo> plaisthos: I can pull a list of git commits from these users and pass it via Pam, to see if they are trivial enough to just be ignored or "capture" the ownership of them
<djpig> dazo: okay, sounds like a good idea
<plaisthos> dazo: we need to take a look first I think
<plaisthos> - Mathieu GIANNECCHINI <mat.giann@free.fr>
<dazo> we should just be careful who looks at what ... so we can claim the clean-room approach if needed
* uddr has quit (Quit: Client closed)
<plaisthos> that is tls-export-cert 
<plaisthos> yeah that is why I am not looking at them
* uddr (~uddr@185.17.127.225) has joined
<djpig> plaisthos: why do we need to look at it first? To filter out the obviously trivial ones?
<plaisthos> the tls-export-cert sounds like non-trivial and also like something someone can look at, document it, revert it and then give the result to me that I can reimplment it
<dazo> okay, I can have a look at all these things and pass it via Pam.
<djpig> okay, sounds like a plan
<plaisthos> the tls-export-cert is probably less than a day of work for me 
<plaisthos> so just reimplementing it and then be good would probably the easiest
<plaisthos> but I need someone else to help me with that for the document+removal step
<djpig> does anyone have anything else to discuss in today's meeting? Otherwise I think we can end it here.
<dazo> tls-verify is not exactly trivial
<plaisthos> dazo: hm?
<dazo> tls-export-cert dumps the certificate to a file in a directory before the tls-verify script is run
<plaisthos> yeah that sounds not very complicated
<plaisthos> I know both the OpenSSL and OpenVPN tls verify part well enough to just implement that in less than a day
<djpig> I have noted the various people that have volunteered for stuff one the Wiki page
<djpig> on*
<dazo> yeah, feature wise it's not complicated ... it's more the OpenSSL calls to fetch the certificate and write to a file which is the big chunk of code
<plaisthos> the tls verify callback of OpenSSL already gives you a stack of certificates. Iterating through them and then calling the X509 to PEM function and writing that to a file is not  very complicated
<djpig> I will leave now, if you guys want to add anything more do it yourselves :)
<rob0> djpig was a pretty good novaflash today :)
<dazo> +1
<d12fk> no reason to insult him =)
<dazo> :D
<d12fk> heading out as well o/
<plaisthos> I actually wrote that code for OpenVPN 3 as quick & dirty hack to print me the certificates of a test server of COnnect team since that was easier/quicker than to get the certificate from them...
<rob0> Who did I insult, djpig or novaflash? ;)
<plaisthos> djpig, dazo can one of you take the lead on looking through the remaining commits?
<plaisthos> take the "] OpenVPN Linking Exception - current status report update July" as starting point
<dazo> plaisthos: I can do that ... was the list of e-mail addresses in this chat the complete list?
<djpig> dazo: yes, that was the whole list from that email
<plaisthos> chekc that email. That should be the full list. 
<dazo> ahh .. will do!
<dazo> I'll ignore Bottomley in this round, as we will just revert that.
<plaisthos> you can double check with the authors.txt in our license change repo
<dazo> +1