This is the IRC Log for the Software Development meeting of 23 November 2018.

All times are EST ( UTC-5 ) ( Eastern North America ).



{{{
--- Log opened Fri Nov 23 15:00:17 2018
15:00 + bdmc [bdmc] joined #cacert-devel
15:00 Irssi: #cacert-devel: Total of 12 nicks [2 ops, 0 halfops, 0 voices, 10 normal]
15:00 Irssi: Join to #cacert-devel was synced in 1 secs
15:01 = FD [f.dumas@80.82.24.20] quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:02  GuKKDevel> hola
15:02  ted> Hi there...
15:04  ted> SHould we just begin?
15:05  bdmc> Sounds like an idea.
15:05  ted> So, who wants to start, and with which topic?
15:06  GuKKDevel> someone to do the protocol?
15:06  bdmc> I was wondering whether I should try including the MySQL changes in my 1444, so that can be used to update Release for testing.
15:07  bdmc> GuKKDevel: Protocol?  You mean be Chairman, or something else?
15:07  GuKKDevel> do minutes
15:08  bdmc> I would volunteer, but I don't know where they go or what the format is.
15:08  ted> Just start with https://wiki.cacert.org/Software/Meeting/20181123
15:08  GuKKDevel> https://wiki.cacert.org/Software/Meeting/20181109?highlight=%28CategorySoftwareMeeting%29
15:09  GuKKDevel> OK Ted was faster
15:09  bdmc> I found that, too.
15:09  bdmc> OK, I can try.
15:09  ted> And don't think too much about format... :-)
15:09 ~jandd> hello
15:09  GuKKDevel> thanks
15:10  GuKKDevel> hello jan
15:10  GuKKDevel> did you notice the spam from yesterday in some chanels?
15:11  bdmc> Has anything happened with the "Top Priorities" item about 1442 and 1444 going to the Old Testserver?
15:12 + FD [f.dumas@80.82.24.20] joined #cacert-devel
15:13  ted> At the moment bug-442 is installed on the testserver
15:13 ~jandd> GuKKDevel: yes, but I have no idea what to do about it because all channels are public
15:14  ted> But merging bug-1442 into the testserver branch was quite some work, since the testserver branch is already far away from the release branch
15:14  bdmc> ted: OK, I don't think that there would be any issue with adding 1444, as long as it didn't reverse the 1442 changes.
15:14  ted> Probably there are still merge errors in the code,
15:14  bdmc> ted: Yes, I understand.  I saw those messages.  I thought that I saw that you were considering putting Release on to that server.
15:15  ted> I'm just working on creating a new "base" branch for the testserver from release
15:15  ted> Jan has proposed to call it "Integration"
15:16  bdmc> Sounds reasonable.  I suspect that none of us "programmers" can help with this, can we?
15:16  ted> Hmm...
15:17  ted> Don't think so. That's a job that has to be done by a single person...
15:17  bdmc> And someone who has access to the test server.
15:17  ted> Yes, this makes things easier.
15:18  ted> I'm currently following the branch testserver-mods, which was intended for this job
15:18  bdmc> I paused for a bit, waiting to hear more about this project.
15:19  bdmc> Is testserver-mods other, older changes moving forward from Release?
15:19  ted> The last changes to testserver-mods have been made 5 years ago
15:19  bdmc> And Release is older?
15:20  ted> No, release is quite recent, since I merged in the newest tarball a few weeks ago
15:20  bdmc> OK
15:21  ted> The last bug-branches have been merged into release three years ago
15:21 ~jandd> it would make more sense to create a new branch from release then and merge new functionality into that new branch and use it on the test server
15:22 ~jandd> the branch in production (aka "release") should always be the oldest active branch
15:22 ~jandd> ... at least this is what most/all bigger projects I worked on do
15:23  ted> At least in theory...
15:23  GuKKDevel> but how can we be sure then, that all merges into testserver are replikated
15:23  bdmc> I tend to agree with Jan.
15:23 ~jandd> we could rebase the branch on the test server onto release and push it to a new branch on git.cacert.org/github
15:24  ted> Which branch of the testserver? testserver-stable?
15:24  bdmc> Or simply wipe the test server ( backing up first ), and install a clone of the Prod server. ( Release )
15:25 ~jandd> ted: the branch that is currently checked out in the working copy there
15:25 ~jandd> bdmc: we already have test, test2 and test3. I think it would be a good idea to find out what is deployed on test and test2 (test3 has been freshly setup in the last few weeks)
15:26  ted> What will a rebase of that branch bring us? There are loads of new features checked into that branch that never made their way to release
15:26  ted> s/checked/merged/
15:27 ~jandd> ted: if these features are not tested enough / not properly reviewed I aggree to start from scratch
15:27  bdmc> Do we have a history of those changes?  Can they be applied ( re-applied ) to a new copy of release as we move forward?
15:27 ~jandd> if the branch is tested / reviewd a rebase would provide us with a clean baseline of changes that are not in release yet
15:28 ~jandd> bdmc: a git rebase would do exactly that
15:28  ted> Some of them are almost ready to be sent off, but not all of them. And I don't have a complete overyiew on what has been merged in.
15:28  bdmc> Thank you.  I am not a git guru!
15:28  ted> So, I'm afraid we'll have to go for the clean cut
15:28 ~jandd> I teach git to development teams at work :-)
15:28  bdmc> B-)
15:30 ~jandd> a rebase would at least give a clean list of commits that need to be checked but I agree that creating a clean integration branch from release and merging the commits that are wanted on the test server would be better
15:30  ted> So we are resolved. :-)
15:31  ted> I was distracted a bit this week, so I've not progressed as far as I hoped.
15:31  bdmc> Completely understand.  We all know that "life" must come before CAcert ( unfortunately ).
15:32  ted> But unless some other problems should pop up I hope to get the clean "Integration" branch next week.
15:32  ted> If it works out extremly well maybe even on Monday
15:32 * ted grins hopefully.
15:32 ~jandd> I had no time besides some infrastructure cleanups after the recent OTRS update either. All test containers have proper IPv6 connectivity now
15:33  bdmc> Isn't it nice to move into this century?
15:34  bdmc> On another topic, I remember seeing some conversation about the updates to the Roots.  Any reportable progress there?
15:34  ted> Once we have the integration branch, it should be easy to create a new branch based on integration, with bug-1442 and 1444 merged in
15:35  ted> This could be tested on the old testserver, and even be installed on the new one to see what will happen.
15:35  GuKKDevel> should we drop the windows installer msi?
15:35  bdmc> ted: I LIKE this idea!
15:35  ted> Concerning roots:
15:36  ted> GuKK: I'd like to drop it for the moment, to concentrate on the certs themselves.
15:36  GuKKDevel> agreed
15:36  ted> But I noticed that we'll have to update the signatures on the CAP forms
15:36  bdmc> Can "modern" Windows ( 7+ ) use the same PEM ( or other ) files that we can?
15:37  ted> bdmc: The certificates did not change since XP
15:37  bdmc> B-)
15:37  bdmc> That was re: MSI installer.
15:37  ted> But maybe the ways to get them installed... though I don't really think so.
15:38  egal> we still have quite a lot of preprinted cap-forms ... ;-)
15:38  ted> I hope that a new installer created with the current tool would also run on Windows 10
15:38 ~jandd> bdmc: native Windows certificate handling requires DER encoded certificates with a .crt file name extension
15:38  egal> (some years ago we had an additional flyer explaining, why the class-3-certificate on the CAcert-flyer is not correct anymore
15:38  bdmc> jandd: But we can generate those, as well as PEM, can't we?
15:39  ted> They are already
15:39  GuKKDevel> already done in bug-1305
15:39 ~jandd> openssl x509 -inform pem -outform der -in cert.pem -out cert.crt :-)
15:39  bdmc> So there really isn't any reason for a special installer for Windows, correct?
15:40  ted> The installer is really nice to have! But not absolutely essential
15:40  GuKKDevel> we provide the certs in crt, der and txt
15:40 ~jandd> I do not know what the installer does besides calling the windows certificate management. I'm no windows user so I cannot tell :-)
15:40  ted> The problem on windows is, when doubleclicking the *.crt file it installs the thing to the current user's environment.
15:41  GuKKDevel> does some translations also
15:41  ted> The installer lets you install the certs in the machine's environment (for all users)
15:41  GuKKDevel> I#m testing on win 10 but haven't got all necesssary tools til now
15:41  ted> Of yourse you can do that manually, but you'll have to know what you do.
15:42  bdmc> ted: Are there "understandable" instructions to do the "machine" install, or does that require ( I expect so ) Administrator rights?
15:42  GuKKDevel> used th git root-cert-installer
15:42  ted> GuKK, do you know the certificate plugin of the Management Console (MMC)
15:43  ted> BDMC: Of course this need admin rights.
15:43  GuKKDevel> not really
15:43  ted> Moment, 'll have to look something up...
15:43  GuKKDevel> I made my first steps with the tool you told us about in the mailing list
15:44  ted> WiX?
15:44  GuKKDevel> yepp
15:44  GuKKDevel> and saxon-he
15:44  ted> Ahh. Yes, needs some work initially...
15:45  bdmc> However, we could really publish an updated Node 3 while "we" are working on the Windows Installer, couldn't we?
15:45  ted> https://wiki.cacert.org/HowTo/InstallCAcertRoots shows how to install the roots manually.
15:45  ted> Quite detailed and quite lengthy...
15:46  ted> Probably not ideal for part time admins...
15:46  bdmc> ted: Could we put a link to that at the top of the page?  For people who are interested?
15:47  ted> Top of which page? The IRC channel? Or the CAcert page?
15:47  bdmc> I suppose, on the other hand, that only people who are both motivated and knowledgeable would go to the HowTo.  ( Node 3 )
15:47  bdmc> ted: the last was the answer to your question
15:49  ted> Ahh, IC... The certificate download page of www.cacert.org
15:49  bdmc> Do I understand that everything ( except the Windows Installer ) is ready and Node 3 could be updated "today?"
15:49  bdmc> ( within a certain range of today )
15:49  ted> No, I noticed that we still have to update the CAP forms
15:49  ted> Place the new fingerprints
15:50  bdmc> With the signatures ( fingerprints ) the two new roots.
15:50  bdmc> ( the = of the )
15:50  ted> Exactly.
15:50  GuKKDevel> I pulled a new request on this three days ago
15:51  ted> I assigned issue 1305 (the new roots) to GuKK so he can do the software changes.
15:51  ted> I'd do them myself, but then I cannot review. :-)
15:52  ted> That's an easy change, probably everyone could do it. Find the old fingerprints and replace them with the new
15:52  GuKKDevel> ted: they are done
15:53  ted> Ahh, that was what you meant with the "pull"... :-)
15:53  ted> Have not been on Github for several days
15:54  ted> OK, I'll have a look
15:54  ted> during the weekend or next week
15:54  GuKKDevel> only need to delete the windows installer
15:55  ted> Yes, do that for the moment.
15:57  ted> Currently I'm not sure what has to be done on the signer for the new certs. Probably the files have to be installed there also.
15:57 ~jandd> yes the signer will need the new certificates
15:58  bdmc> Makes sense.
15:59 ~jandd> I'm not sure whether this can be done in production without a visit to the data center. We will need to ask the critical admins.
16:00  ted> As I understood Wytze he seems to be assume a ata center visit.
16:00  ted> But yes, we should ask explicitly
16:01  ted> OK, but from my perspective we're through with the top priorities now.
16:01 ~jandd> makes sense. We have all the serial line magic to avoid having the signer on an online machine.
16:01  bdmc> I had hoped to hear from Peter, but I guess that he is busy with "real work."
16:02  ted> We stumbled on another thing... The Class 3 root will expire in 2020
16:02  egal> 2021
16:02  ted> . Yes, 2021
16:02  bdmc> Only two years
16:02  ted> . We issue certs with two years lifetime
16:03  bdmc> Would it be prudent to create a newer one immediately?
16:03  ted> How does software behave if the root is expired but the cert is still valid?
16:03 ~jandd> proper TLS stacks will fail to validate the chain
16:03  ted> This is what I was fearing...
16:04  ted> So we have toll May 2019 to repeat the job...
16:04  ted> At least now we know the process... :-\
16:05  egal> ... or to resign it again within the next two years ... using the original private key
16:05  egal> (as we did 8 years ago)
16:06 * ted agrees egal.
16:06  ted> But this raises the question why the 10 years expiry was selected at all?
16:08  bdmc> ted: Keeps us on our toes?  We have to DO something every decade.
16:08 ~jandd> if we don't create a resigned certificate before may we need to educate users that they will have to reconfigure their servers/clients to use the new class 3 certificate in the chains they deliver to relying parties
16:09 ~jandd> ... because of the issue with a CA certificate expiring before a endpoint certificate
16:09  ted> Jan: this is an issue
16:09  GuKKDevel> can we wait until we know if CAcert stays or fails
16:09 ~jandd> seems legit
16:10  GuKKDevel> with money and so?
16:10  egal> about the lifetimes of root and class-3-certificates we checked several roots during/after our secure-u-meeting:
16:10  ted> bdmc: I guess that "normal" CAs reduce the lifetime of their "working" keys, because since they are in daily use they may be compromised without anyone noticing. 10 years reduces the risk on that.
16:10  egal> 23:31 < egal> google hat ca. 4 1/2 jahre fuer class 1 und class 3
16:11  egal> 23:33 < egal> godaddy: 30 jahre fuer class1 und class3, 2 jahre fuer godaddy.com
16:11  ted> (10 years or less)
16:11  egal> 23:35 < egal> microsoft: 24 jahre class 1, 5 jahre class 2, 2 jahre microsoft.com
16:11  ted> 10 years were more common when CAcert's keys were created. :-)
16:12  ted> But from this perspective at CAcert there's no difference between Class 1 and Class 3
16:12  ted> So, we could follow this argumentation and sign the Class 3 to the same expire as the Class 1 (which is a bit more then 10 years).
16:13 ~jandd> PKIX best practice is to use short lifetimes and have proper procedures for regular resigns or new intermediary CA certificates
16:14  ted> Yup. But the Class 3 was (IMHO) not meant to be a real intermediary CA
16:14  ted> It was intended to sign the "extended verifocation" certs
16:14  ted> . The ones of the assured users
16:16  ted> The way they are currently used, both root keys are as easily (or difficultly) compromised
16:16  ted> They also have the same crypto, so why differ the lifetime?
16:18  ted> But I agree, it's quite academic.Class 1 is valid to 2033, Class 1 with 10 years from now til 2029...
16:20  ted> OK, I'd propose that we finish for today, and think a bit about this problem. :-)
16:21  bdmc> Does this mean that we are holding off on updating Node 3, or is this a separate problem?
16:21  ted> Seperate problem IMHO
16:22  ted> First fire out the thing, then, maybe, do the same in 6 months again.
16:23  bdmc> I agree.  This issue ( OLD Roots on Node 3 ) has been hanging around for years, and it would be an easy way to help our users.
16:23  ted> Yes. And if we do it again it won't need this long again
16:25  ted> I guess board should be made aware of this May 2019 issue, so that everyone at least knows...
16:26  bdmc> I will post a message to board-private, briefly stating that.
16:26  bdmc> This is the Class 3, only, correct?
16:26  ted> Yup
16:27  bdmc> But, at the same time, that failure would be as bad as the Class 1 failing.
16:28  GuKKDevel> how shall the users be informed about the new roots?
16:28  bdmc> Well, unless there is something else, I need to get ready to go to work.  ( I will leave the log running. )
16:28  ted> As Dirk said, if we only re-sign the Class 3 the problem is not that grave.
16:29  bdmc> GuKKDevel: I agree. This is an issue.  Just a note on Node 3, and an article on the Blog ( the front page of cacert.org? )
16:29  GuKKDevel> but they will have to install the new certs
16:29  ted> GuKK: Did you add the text to the CAP forms as I proposed?
16:29  GuKKDevel> yes
16:30  ted> So this is another channel of notifying the users.
16:30 * ted grins.
16:30  GuKKDevel> but I think about all that only react when support informs them about the expiring
16:31  ted> Hmm...
16:31  GuKKDevel> can there be a note in that mail?
16:31  ted> You want to send out a mail to all users?
16:31  GuKKDevel> if it must be
16:32  ted> It would be an option. But I'd prefer to have board's opinion on that.
16:32  GuKKDevel> sure
16:33  ted> Every registered user, or only those with valid certificates?
16:33  ted> Maybe even an additional note on the certificate issuance page
16:34  ted> Or we postpone the mailing till we know what to do with the May 2019 problem...
16:35  egal> i would postpone it until we have a decision for the may2019-issue ...
16:35  GuKKDevel> but if we sign the user certs with our resigned root3 cert, and only the old one is installed, what happens then?
16:35  ted> So, installation first, mailing/notification second. :-)
16:36  ted> GuKK: If they were accepted before they will be after.
16:36  ted> The keys are the same
16:36  egal> if we don't change our private key (resign the old one) they remain valid ...
16:37  GuKKDevel> Ok, the chain isn't broken then?
16:37  ted> No
16:37  ted> Since the end user certs do not have the Authority Key information
16:38  ted> (or how was it called)
16:38  ted> (X509v3 Authority Key Identifier)
16:41  GuKKDevel> good
16:42  ted> So, do we finish for today, or are there still urgent issues?
16:43 ~jandd> lets finish
16:43  GuKKDevel> I agree
16:44  ted> So let's try to meet in two weeks again, but maybe I'll have to excuse myself.
16:44  GuKKDevel> ok for me
16:45  GuKKDevel> would be 2018-12-07 20:00 UTC?
16:45  FD> We forgot to ask for a volunteer at writing the summary of the meeting. Should I do it this time ?
16:46  GuKKDevel> brian volnteered
16:46  ted> bdmc had voplunteered
16:46  FD> Ok, failed to see it.
16:46  ted> But we'll come back to your offer nect time. :-)
16:46 * GuKKDevel grins
16:47  ted> Then, thanks for attending! Progress is slow, but noticable!
16:47  ted> Good night, or have a nice day.
16:48  FD> Thank you for the interesting talk you had together, as usual. Good night !
16:48  GuKKDevel> good night
16:50  egal> good night ...
17:01 - FD [f.dumas@80.82.24.20] left #cacert-devel (Textual IRC Client: www.textualapp.com)
18:11 = egal [egal@45.77.40.159] quit (Ping timeout: 121 seconds)
18:13 + egal [egal@i577B4BED.versanet.de] joined #cacert-devel
18:20 = egal [egal@i577B4BED.versanet.de] quit (Ping timeout: 121 seconds)
18:20 + egal [egal@45.77.40.159] joined #cacert-devel
18:25 = GuKKDevel [quassel@xdsl-78-35-142-89.nc.de] quit (Connection closed)
18:25 = GuKKDevel_log [GuKKDevel@xdsl-78-35-142-89.nc.de] quit (Connection closed)
18:32 = ted [00000000@localhost] quit (Quit: http://www.kiwiirc.com/ - A hand-crafted IRC client)
22:03 = nemunaire [nemunaire@LFbn-1-949-99.w86-247.abo.wanadoo.fr] quit (Quit: quit)
--- Log closed Fri Nov 23 23:40:03 2018
}}}