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