Hi,
Here's the summary of the previous IRC meeting / sprint.
---
COMMUNITY MEETING
Place: #openvpn-devel on irc.freenode.net
List-Post: openvpn-devel@lists.sourceforge.net
Date: Thursday 21st Jun 2012
Time: 18:00 UTC
Planned meeting topics for this meeting were on this page:
<https://community.openvpn.net/openvpn/wiki/Topics-2012-06-21>
Next meeting will be announced in advance, but will probably be on the same
weekday and at the same time. Your local meeting time is easy to check
from services such as
<http://www.timeanddate.com/worldclock>
or with
$ date -u
SUMMARY
Cron2, dazo, habets, jamesyonan, krzee and mattock participated in this
meeting.
--
Discussed the "management: Don't require DAF_INITIAL_AUTH to send
ADDRESS/DISCONNECT messages" patch:
<http://thread.gmane.org/gmane.network.openvpn.devel/6456/focus=6457>
Decided to ask verification from author before merging this patch.
--
Discussed the "OCC ping" patch:
<http://thread.gmane.org/gmane.network.openvpn.devel/6619>
A few concerns were raised regarding the purpose of this patch and
possible security implications. Decided to ask the author about the
purpose of this patch and then reconsider the implementation.
--
Discussed the "Remove ENABLE_INLINE_FILES conditionals" patch:
<http://thread.gmane.org/gmane.network.openvpn.devel/6740/focus=6746>
Jamesyonan gave this patch an ACK.
--
Discussed the "Remove ENABLE_CONNECTIONS ifdefs" patch:
<http://thread.gmane.org/gmane.network.openvpn.devel/6740/focus=6744>
Jamesyonan gave this patch an ACK.
--
Discussed the "Fix clang warnings for conversion from unsigned<->signed"
patch:
<http://thread.gmane.org/gmane.network.openvpn.devel/6740/focus=6745>
No consensus was reached, but there were many points and counterpoints.
See full chatlog at 22:41 - 23:04.
--
Discussed the "SSL engine support" patch:
<http://thread.gmane.org/gmane.network.openvpn.devel/6730>
<http://thread.gmane.org/gmane.network.openvpn.devel/6734>
<https://github.com/alonbl/openvpn/tree/engine>
<http://blog.habets.pp.se/tmp/blah.patch>
Jamesyonan gave this patch an ACK, but decided to run it by Adriaan just
in case.
--
Discussed the OpenVPN 2.3-alpha2 release briefly. Mattock now has the
Windows code-signing certificates, so it should be possible to make the
release next week.
---
Full chatlog as an attachment
--
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc
irc freenode net: mattock
20:57 <@mattock> topic list here:
https://community.openvpn.net/openvpn/wiki/Topics-2012-06-21
20:57 <@vpnHelper> Title: Topics-2012-06-21 – OpenVPN Community (at
community.openvpn.net)
21:00 < ecrist> cron2: just 32-bit stuff, still
21:01 < ecrist> I can have the 128-bit stuff thanks to openvpn
21:01 < ecrist> :)
21:01 <@cron2> heh :)
21:02 <@mattock> ok, everybody set
21:06 <@cron2> james around?
21:07 <@mattock> jamesyonan?
21:08 <@mattock> what about dazo?
21:08 <@cron2> yup... half of the patch review is waiting for the master's voice
21:08 <@dazo> I'm here
21:10 <@jamesyonan_> hi, I'm here -- for some reason my IRC client isn't using
my usual name
21:10 <@mattock> ok, let's begin
21:11 <@cron2> great
21:11 <@mattock> maybe start with this one?
http://thread.gmane.org/gmane.network.openvpn.devel/6456/focus=6457
21:11 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org)
21:12 <@dazo> jamesyonan_: I believe you might give a better verdict on that one
21:13 <@jamesyonan_> patch seems like it might break stuff
21:16 <@jamesyonan_> this changes the management interface semantics
21:16 <@dazo> I personally don't understand what the benefit of this patch is,
tbh ... It claims to "solve" something, but I don't understand
why this change is needed
21:17 <@cron2> as far as I understand, these two messages are not sent for
*all* client connects, but only for password-authenticated logins
21:17 <@cron2> (and thus, missing otherwise)
21:17 <@cron2> but I won't claim to understand management interface semantics
21:17 <@jamesyonan_> well it looks like the author wants >CLIENT messages for
all connections, even those that don't require auth
21:17 <@cron2> that's how I read it
21:19 <@dazo> Can we imagine any reasons why that's an advantage?
21:19 <@jamesyonan_> does his comment "DAF_INITIAL_AUTH will only be set …"
refer to behavior before or after the patch is applied?
21:20 <@dazo> It seems to be related to this discussion:
http://thread.gmane.org/gmane.network.openvpn.devel/6442/focus=6444
21:20 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org)
21:21 <@jamesyonan_> I would want to hold off on this one until we get more
clarification on how this will affect existing managment
interface clients
21:21 <@mattock> sounds good
21:22 <@mattock> anything else, or shall we move on to this:
http://thread.gmane.org/gmane.network.openvpn.devel/6619
21:22 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org)
21:22 <@dazo> agreed ... Let's provide a feedback, where we need far more
testing info ... and a better explanation why this is needed in
Adrien's eyes
21:23 <@cron2> well, the explanation is obvious "I want to see my clients
connect, even if they are not using password auth" :-)
21:24 <@mattock> then we still have the "does this affect existing management
interface clients"
21:24 <@cron2> yeah, that's the big one
21:25 <@mattock> more testing/reading of code later?
21:25 <@dazo> I'm not sure I still see the purpose ... and the relation to
password auth ... but I don't know the management interface well
enough to really understand these details well enough
21:28 <@mattock> next patch?
21:30 <@cron2> which one?
21:30 <@dazo> OCC ping?
21:30 <@mattock> http://thread.gmane.org/gmane.network.openvpn.devel/6619
21:30 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org)
21:32 <@cron2> I'm not sure I fully understand that one - well, it sends occ
pings and occ ping-replies, but then just discard the reply -
shouldn't it check somewhere that replies are coming in?
21:35 <@mattock> jamesyonan: what do you think?
21:35 <@jamesyonan_> in general, I do like the idea of changing ping to be more
conservative on mobile devices
21:36 <@jamesyonan_> not sure, off hand, if this is the right way to do it
21:36 <@jamesyonan_> also, keep in mind that there's a known DTLS vulnerability
with ping response that we don't want to repeat here
21:37 <@jamesyonan_> OpenVPN protocol is pre-DTLS but shares many of the same
characteristics
21:40 <@jamesyonan_> the bigger problem to solve is this -- how can we retain
reasonable keepalive functionality on UDP connections
without forcing a mobile device to xmit pings when no
traffic would otherwise be sent/received
21:41 <@mattock> so currently a reasonable keepalive is not possible? or does
this patch affect that aspect?
21:42 <@jamesyonan_> well it seems like the patch author is thinking about the
problem of power management on mobile, but I don't see the
details of how adding a ping reply will help to solve this
problem
21:43 <@cron2> I think the key aspect is that this is purely client-controlled,
so the client can decide how often it wants to send/receive ping
stuff
21:43 <@cron2> while the normal ping stuff needs to be symmetric between client
and server to work - so you can't unilateraly change it on the
client, without adapting the server as well
21:44 <@jamesyonan_> but how does the server know the client is still there in
the case that the client controls the ping initiation?
21:45 <@jamesyonan_> if the server is forced to retain client instance objects,
that can be a DoS vector
21:45 <@cron2> no idea... maybe run occ-ping itself, in the opposite direction
21:46 <@jamesyonan_> but that seems to defeat the power-management purpose if
both client and server are initiating pings
21:47 <@mattock> yeah
21:47 <@mattock> maybe we should ask the author what the core reason for this
patch is?
21:47 <@jamesyonan_> I think for mobile power management, it might be better to
just have the client do a disconnect when it notices that
the connection isn't being used
21:48 <@jamesyonan_> and then have it bring back the connection dynamically
when there is usage
21:48 <@jamesyonan_> this way the server can also free the client instance
object for the client, during the inactive state
21:49 <@mattock> yep, sounds right
21:50 <@mattock> ah yes, the author says it about saving battery
21:51 <@jamesyonan_> I also have a bit of concern because one of the OpenSSL
DTLS security vulnerabilities I read about recently was
facilitated by the fact that DTLS also has an internal
ping that is echoed by the receiver
21:51 <@mattock> I
21:51 <@mattock> oops
21:51 <@jamesyonan_> we need to understand the details of this vulnerability
before we attempt to implement an echoing ping
21:52 <@mattock> I'd say NACK for now and ask the author if there's any hidden
benefits (besides
21:52 <@mattock> theoretical power savings)
21:52 <@cron2> ... and it should be checked that this actually works... :)
21:52 <@mattock> if not, NACK, if yes, look into the implementation details
21:52 <@mattock> cron2: yes, that too :D
21:53 <@mattock> next patch?
21:53 <@mattock> http://thread.gmane.org/gmane.network.openvpn.devel/6619
21:53 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org)
21:53 <@cron2> that was occ ping?
21:54 <@mattock> yes, sorry
21:54 <@mattock> this one:
http://thread.gmane.org/gmane.network.openvpn.devel/6740/focus=6746
21:54 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org)
21:55 <@dazo> jamesyonan_: any concerns about removing all these #ifdef's? ...
mainly to improve the code readability
21:55 <@cron2> 3/6, yes. I think it's making the code more easy to read, not
changing any functionality, so is OK. What I don't now, and why
I was asking for James' opinion on this is whether there is a
use case for not having ENABLE_INLINE_FILES turned on
21:55 <@cron2> what dazo said
21:56 <@jamesyonan_> I'm generally fine with this
21:57 <@jamesyonan_> at one time we sort of fell over ourselves making sure
that every added feature had an ifdef so code would
continue to run on highly memory-constrained platforms
like OpenWRT
21:57 <@jamesyonan_> but this is a feature that doesn't add very much code and
is almost always turned on
21:57 <@dazo> I would argue that inline files makes quite a lot of sense in
embedded environments
21:57 <@mattock> and even those platforms grow more powerful in time
21:58 <@jamesyonan_> agreed
21:58 <@mattock> so it makes sense... ACK?
21:59 <@cron2> it actually cannot easily be turned *off* right now, as it would
need patching syshead.h
22:01 <+krzee> +1 dazo
22:02 <@mattock> krzee just got into the list of attendees
22:02 * krzee cheers
22:03 <@jamesyonan_> +1 for removing ENABLE_INLINE_FILES
22:03 <@jamesyonan_> i.e. make it permanently enabled
22:03 <@mattock> ok, I'd interpret that as an ACK :P
22:03 <@jamesyonan_> yes
22:03 <@mattock> next patch?
22:03 <@mattock>
http://thread.gmane.org/gmane.network.openvpn.devel/6740/focus=6744
22:03 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org)
22:04 <@dazo> Same arguments as the previous one
22:04 <@cron2> +1
22:05 <@mattock> jamesyonan: ok with you?
22:06 <@dazo> (this one is a bit messier to review)
22:08 <@jamesyonan_> any idea how much code size is saved if these are turned
off?
22:08 <@cron2> no idea, but I can go and find out
22:09 <@jamesyonan_> I think ifdefs are justified if the code size is large and
if the feature is arguably used by a small % of users
22:09 <@cron2> it's on-by-default via syshead.h
22:10 <@jamesyonan_> probably okay then -- presumaby if embedded folks needed
to cut it out, they would have added a configure option
22:10 <@cron2> still compiling...
22:11 <@cron2> haha
22:11 <@cron2> ../../../openvpn.git/src/openvpn/options.c: In Funktion
»add_option«:
22:11 <@cron2> ../../../openvpn.git/src/openvpn/options.c:5001: Fehler: »struct
options« hat kein Element namens »force_connection_list«
22:11 <@cron2> compiling with /* #undef ENABLE_CONNECTION */ fails
22:13 <@cron2> ok, add #ifdef (for testing), size with default options:
22:13 <@cron2> text data bss dec hex filename
22:13 <@cron2> 545068 1632 1268 547968 85c80 src/openvpn/openvpn
22:13 <@cron2> size without ENABLE_CONNECTION
22:13 <@cron2> text data bss dec hex filename
22:13 <@cron2> 537980 1632 1268 540880 840d0 src/openvpn/openvpn
22:13 <@dazo> ~7KB?
22:13 <@cron2> yeah, that's somewhat surprising
22:14 <@cron2> (that's code + static data)
22:14 <@dazo> try both with --enable-small? as that would be typical for
memory restrained systems ... a
22:15 <@dazo> and these two #ifdef's add some info to the --help screen and
logging stuff and such
22:15 <@mattock> and while cron2's computer is working, perhaps review the next
one?
22:15 <@cron2> this will take a while
22:15 <@mattock> snack while we're waiting would be this:
http://thread.gmane.org/gmane.network.openvpn.devel/6740/focus=6745
22:16 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org)
22:16 < shuffle2> is there a way to programmatically do the equivalent of
telling windows to bridge your main nic and the openvpn tap
device?
22:16 <@cron2> shuffle2: not inside openvpn, surely inside windows API "somehow
the gui must do it"
22:17 < shuffle2> or is there another way to do it? it's somewhat annoying
since it means the machine will request dhcp and etc again
for the new bridge device created by windows
22:18 < shuffle2> just need to route the traffic on openvpn device onto the
network somehow
22:19 <@dazo> if you insist on bridging, cron2 gave the answer
22:19 < shuffle2> no, that creates another device
22:19 < shuffle2> i mean with using only the real nic and the openvpn device
22:20 <@dazo> can we please take this discussion after the developers meeting?
22:20 <@mattock> cron2: how's the compile going?
22:21 <@dazo> that "Fix clang warnings for conversion from unsigned<->signed"
... I'm kind of sceptical to such fixes generally ... as it might
be hiding other issues, instead of solving the root cause
22:21 <@cron2> --enable-small, #define ENABLE_CONNECTION
22:21 <@cron2> text data bss dec hex filename
22:21 <@cron2> 499292 1616 1268 502176 7a9a0 src/openvpn/openvpn
22:21 <@cron2> --enable-small, #undef ENABLE_CONNECTION
22:21 <@cron2> text data bss dec hex filename
22:21 <@cron2> 491932 1616 1268 494816 78ce0 src/openvpn/openvpn
22:21 <@cron2> (now I'll be kicked)
22:22 <@dazo> I'm wondering if it would be a better approach to rather look at
the argument declarations of md_ctx_update() instead
22:23 <@dazo> hmm ... still ~7KB ... that's quite a lot
22:23 * dazo would have expected it to be much less
22:23 <@cron2> hard to estimate, in the patch set you have chunks that only
have #ifdef and then another chunk "1000s of lines further down"
with the #endif
22:25 <@dazo> yeah
22:25 <@dazo> and you also have the MANAGEMENT_QUERY_REMOTE stuff too ... and
that removals together with ENABLE_CONNECTION scares me a little
bit
22:25 <@dazo> does that mean that you cannot disable management interface?
22:26 <@cron2> nah, that's a specific sub-option of management interface
22:27 <@dazo> oh true ... so if management is disabled, that should not add
management_query_remote stuff anyway
22:27 <@cron2> building with --disable-management now :)
22:28 <@dazo> so the bottom line is ... is ~7KB enough to scare us away from
this patch? .... I would definitely expect the code to be
smaller without management enabled
22:31 <@cron2> text data bss dec hex filename
22:31 <@cron2> 446545 1584 1264 449393 6db71 src/openvpn/openvpn
22:33 <@dazo> now, that's about 50KB saved
22:34 <@mattock> so, what to do with this patch?
22:34 <@dazo> I'd guess most memory restrained environments would then opt for
disabling management all in all ... otherwise, 7KB isn't
necessarily that much
22:34 <@mattock> ACK?
22:35 * dazo lets jamesyonan_ take the final decision on this one
22:36 <@jamesyonan_> yeah I would say we should have some threshold maybe 10 or
20 KB where a feature should be ifdefable
22:37 <@jamesyonan_> probably if this is just a subfeature of management and
it's under 10 KB, it's not a big deal to remove ifdef
22:37 <@dazo> agreed
22:37 <@jamesyonan_> ack
22:38 <@mattock> two more two go:
http://thread.gmane.org/gmane.network.openvpn.devel/6730
22:38 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org)
22:39 < habets> I'm (Thomas Habets) here, btw
22:39 <@mattock> hi!
22:39 <@dazo> nice!
22:39 * habets waves to everone
22:39 <@mattock> jamesyonan: what do you think about this one?
22:40 <@cron2> mattock: did we come to an agreement about the (const uint8_t*)
stuff?
22:40 <@mattock> which one?
22:40 <@cron2> 6/6
22:41 <@mattock> ah, we might have skipped it
22:41 <@jamesyonan_> personally, I've never had the signed <-> unsigned
warnings find an actual bug
22:41 <@jamesyonan_> so I usually turn off the warnings altogether
22:41 <@mattock> ok, so it was this one:
http://thread.gmane.org/gmane.network.openvpn.devel/6740/focus=6745
22:41 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org)
22:41 <@cron2> yep
22:42 <@jamesyonan_> but the other side of the coin is that some people want
maximum warning sensitivity and then they have to go off
and manually cast everything so they don't get flooded
with false positives
22:43 <@dazo> I looked quickly at the code ... and I think it's better to fix
the data types of these callers ... or do this typecasting after
all ... but typecasting like this might, as well, hide issues
related to overflows ... depending on the caller situations
22:44 <@dazo> DigestCalcHA1(
22:44 <@dazo> IN char * pszAlg,
22:44 <@dazo> IN char * pszUserName,
22:44 <@dazo> IN char * pszRealm,
22:44 <@dazo> IN char * pszPassword,
22:45 <@dazo> (that's the variable declarations of the variables used with
md_ctx_update())
22:45 <@jamesyonan_> yeah, I also notice that he is converting some data types
from char to unsigned char which could actually change
behavior
22:45 <@cron2> well, we'll always have warnings or typecast one way or the
other, if we mix "stringy things" (that want to be "char") with
"crypto things" that usually want uint8=unsigned char
22:47 <@jamesyonan_> well should we use explicit casts when converting between
crypto and string character sequences or just disable the
warnings?
22:48 <@dazo> it's just solving the same issue in two different ways
22:48 <@dazo> with basically the same impact
22:48 <@jamesyonan_> well one could argue that by using explicit casts, and
keeping the warning, when a real bug does surface, you
will see it
22:49 <@dazo> agreed
22:50 <@dazo> I'd probably like to see that those Digest*() functions in
httpdigest.c becomes more "crypto like" (using unsigned char) and
the callers of these Digest*() function can do the typecasting,
where it is most easy to see if this gets right or not
22:50 <@dazo> (probably more easy to see, I meant)
22:51 <@jamesyonan_> I guess I'm in favor of patch as long as author tests that
changes don't break anything (it's not enough in these
cases to assume that adding casts or retyping vars doesn't
change functionality)
22:53 <@mattock> verify that and then ACK?
22:53 <@dazo> I'm just afraid of "hiding" such typecasts too long down in the
call chain ... as that might change the behaviour more hidden ...
if you have them higher up in the call chain, the coder have more
control of what's happening
22:53 <@cron2> for style reasons I'd not cast to (const uint8_t*) but to
(uint8_t*) - the "const" is not a function of the caller but of
the callee
22:53 <@dazo> (after all, these Digest*() functions are quite generic)
22:53 <@cron2> ... and that
22:54 <@cron2> ah
22:54 * cron2 takes the const bit back
22:54 <@dazo> :)
22:54 <@cron2> it *is* a "const char*" already
22:55 <@dazo> it's a const char* in Digest*() and const uint_8* in md_ctx_*()
22:56 < ecrist> cron2: is iroute for ipv6 done yet?
22:56 <@cron2> ecrist: 27 years ago, why?
22:56 < ecrist> troubleshooting a vpn for someone
22:57 < ecrist> Options error: option 'route-ipv6' cannot be used in this
context
22:57 <@jamesyonan_> part of the issue here is that OpenSSL was written before
uint8_t became a standard type for referencing binary
data, or before size_t came onto the scene
22:57 <@cron2> ecrist: spell it "iroute-ipv6", and then it will work
22:58 < ecrist> iroute-ipv6 2607:fc50:1001:3502::/64
22:58 <@mattock> ok, so what to do with
22:58 <@mattock>
http://thread.gmane.org/gmane.network.openvpn.devel/6740/focus=6745
22:58 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org)
22:58 <@cron2> ecrist: your error message talks about "route-ipv6", so I
assumed that an "i" got lost
22:58 < ecrist> hang on, I see it
22:58 < ecrist> thanks.
23:04 <@cron2> mattock: "postpone while we make up our minds" :)
23:04 <@mattock> yeah, I was just about to ask "where did everyone disappear" :P
23:05 <@mattock> http://thread.gmane.org/gmane.network.openvpn.devel/6730
23:05 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org)
23:05 <@mattock> and this:
http://thread.gmane.org/gmane.network.openvpn.devel/6734
23:05 <@vpnHelper> Title: Gmane Loom (at thread.gmane.org)
23:06 <@cron2> I've seen the discussion, Alon seems to be happy, but I don't
understand any of this crypto stuff
23:09 <@mattock> jamesyonan?
23:11 <@jamesyonan_> for SSL engine support, where is the actual patch?
23:12 <@dazo> habets: ^^^
23:12 < habets> sorry
23:13 < habets> slow wireless connection. one sec
23:16 -!- dazo is now known as dazo_afk
23:18 < habets> https://github.com/alonbl/openvpn branch engine. It's Alons
patch in the end. His way was better.
23:18 <@vpnHelper> Title: alonbl/openvpn · GitHub (at github.com)
23:19 <@mattock> https://github.com/alonbl/openvpn/tree/engine
23:19 <@vpnHelper> Title: alonbl/openvpn at engine · GitHub (at github.com)
23:19 -!- dazo_afk is now known as dazo
23:20 < habets> or blog.habets.pp.se/tmp/blah.patch all in all
23:20 < habets> I'll be on better connection in 5m
23:22 <@dazo> I'd say andj should probably also have a look at this patch as
well
23:23 <@mattock> yep, probably makes sense
23:23 <@mattock> jamesyonan: any thoughts on this one?
23:24 <@dazo> habets: just to be sure that I understand the purpose of this
patch ... it's so that you can interact with external SSL engines
to retrieve SSL keys and certificates?
23:25 < habets> dazo: yes. It's not so much "retrieve" as "act as oracle". The
private key never leaves the TPM chip in plaintext. It was
generated inside it and never sees the light of day.
23:26 <@dazo> Ahh, I see
23:27 < habets> the .key file is an encrypted blob. You hand the blob and
"please use this to help me complete this handshake".
23:28 <@dazo> I'm lacking the needed knowledge regarding SSL and TPM to see if
this is a good way to solve it or not ... I put my trust in andj
and jamesyonan_
23:29 <+krzee> "in james we trust"
23:29 <@dazo> krzee: at least when it's related to SSL stuff ;-)
23:29 <@jamesyonan_> sorry, what's the URL to quickly view the patch?
23:30 < habets> http://blog.habets.pp.se/tmp/blah.patch
23:32 <@dazo> (this might be the same?
https://github.com/alonbl/openvpn/compare/master...engine )
23:32 <@vpnHelper> Title: Comparing master...engine · alonbl/openvpn · GitHub
(at github.com)
23:32 <@jamesyonan_> does this work on both OpenSSL and PolarSSL?
23:32 < habets> dazo: yes.
23:32 < habets> jamesyonan_: it's not an implementation for polarssl. If
polarssl has the functionality I don't know.
23:33 <@jamesyonan_> so if I understand this correctly, it allows OpenVPN to
access a private key that resides on an external device
23:34 <@jamesyonan_> where the device has an OpenSSL engine implementation?
23:35 < habets> yup
23:35 < habets> well, in theory it can be more general. It allows for using an
engine to load a key. It doesn't *have* to be on another device.
23:36 <@jamesyonan_> does this interoperate an any way with OS-level key stores
such as Windows cryptoapi, Mac keychain, etc.?
23:37 <@mattock> or could it be extended to do so?
23:37 < habets> There's nothing in the patch that goes outside of OpenSSL
engine plugins. If there is a Windows cryptoapi engine (or one
is made) then this would work with it.
23:39 < habets> probably as-is, since the patch allows for setting parameters
in a standard way
23:40 <@mattock> jamesyonan: does this patch seem ok? we could run it by andj
also
23:40 <@jamesyonan_> I think OpenSSL engine stuff was interesting when it first
came out, but I think in recent years it's been supplanted
by OS-level keystores
23:40 <@jamesyonan_> I think the patch seems reasonable though
23:41 <@mattock> ok, let's have andj look at it later on
23:41 <@mattock> ok, I think that was all
23:41 <@cron2> 2.3alpha2?
23:41 <@mattock> ok, a brief update
23:42 <@mattock> got the digicert certs, did not work out of the box, got new
ones
23:42 <@jamesyonan_> since the OS needs to have drivers for the various crypto
devices, it seems to make more sense to handle at the OS
level, and then maybe have the OpenSSL engine just
interact with the OS-level crypto store
23:42 <@mattock> haven't tested the new ones, will test on Monday (no time
tomorrow/weekend)
23:42 <@mattock> besides that, I think we can release 2.3-alpha2 a.s.a.p.
(dazo?)
23:42 <@cron2> no objections from here
23:43 <@mattock> ugh
23:43 <@mattock> almost midnight here, got to hit the sack
23:44 <@cron2> g'night
23:44 <@dazo> okay, I'll try to get the last acked patches in ... and then I'll
tag the tree ... I'll try to manage that tomorrow
23:44 <@cron2> cool
23:44 <@mattock> I'll summarize the meeting tomorrow
23:44 <@dazo> goodie :)
23:44 <@mattock> 2.3-alpha2 out next week, unless somebody objects
23:44 <@mattock> (or the digicert certificates object)
23:44 <@mattock> :P
23:44 <+krzee> you guys rock o/
23:45 <@mattock> thanks!
