#taskwarrior

/

      • musicmatze[m] has quit
      • pbecking1 has quit
      • pbecking1 joined the channel
      • smokeysea joined the channel
      • smokeysea
        Hello All, How to see time consumed by any particular task (ie., from task start to task stop)?
      • I am on 2.3.0 (debian)
      • pbecking1
        smokeysea: You use a time-tracking extension, or Timewarrior.
      • But you'll need to upgrade to 2.5
      • smokeysea
        pbecking1: thanks. Are you talking about http://taskwarrior.org/docs/timewarrior/stopwat... ?
      • pbecking1
        I mean: Timewarrior comes with a Taskwarrior hook script that integrates the two, so not the stopwatch feature.
      • smokeysea
        pbecking1: ok. Thanks.
      • smokeysea has quit
      • musicmatze[m] joined the channel
      • frenchbeard joined the channel
      • pbecking1 has quit
      • frenchbeard has quit
      • nolash joined the channel
      • kidanger joined the channel
      • vodka joined the channel
      • vodka_ joined the channel
      • smokeysea joined the channel
      • hello all, does any one have latest tw for Debian-Jessie (8.x). From the site I can see it for 7x and Testing only.
      • regagain joined the channel
      • frenchbeard joined the channel
      • nolash has quit
      • nolash joined the channel
      • fkaa joined the channel
      • nolash has quit
      • Got the task 2.51 and timew 1.0 installed on Debian Jessie
      • I am trying to link task with timew on-modify (ref: https://taskwarrior.org/docs/timewarrior/taskwa...)
      • but unable to find ext/on-modify.timewarrior
      • any pointers?
      • Got it
      • smokeysea has left the channel
      • seschwar joined the channel
      • pbecking1 joined the channel
      • pbecking1 has quit
      • polettix joined the channel
      • polettix
        hello all… and Weasel
      • I actually have no trouble with SSL now, but there are a couple things that might possibly be enhanced in the docs and maybe the code
      • First, I’m using a public certificate issued by Let’s Encrypt. The only way I got this to work is to set the CA certificate in the client to the Let’s Encrypt certificate, not the auto-generated one
      • which makes sense on the one hand, but it’s arguably not necessary from a generic standpoint. E.g. browsers don’t require me to install the CA intermediate certificate, they are perfectly fine with getting one single certificate file with my certificate and the intermediate CA certificate immediately after
      • so I tend to see this as either a bug, or a possible enhancement. Ideally, when non-auto-generated certificates are used, there should be no need to set the CA in the client, and all the configuration burder should be on the server side (which means: put the right chain of certificates in the certificate file)
      • From the documentation point of view, the instructions tend to be obscure and to do steps that are not really needed. Think e.g. the configuration of client.cert and client.key on the server side
      • additionally, they don’t make it too clear of the different roles of the CA fields on the server and client side, which might confuse more than one
      • it took me a bit to make a mental model of what is needed where in my case
      • now I probably talked too much as usual, so I’ll retreat in silence :)
      • tls2000 joined the channel
      • gorgabal joined the channel
      • polettix has quit
      • polettix joined the channel
      • pbecking1 joined the channel
      • pbecking1
        polettix: reading...
      • polettix
        sure
      • pbecking1
        polettix: You're right, if a *real* cert works, there is no need for a CA. The CA only exists to take the place of Verisign et al, so a generated cret will eventually point back to some kind of cA.
      • That said, no one has told us how they managed to get an LE cert to work instead. Several have tried...
      • polettix
        pbecking1: fact is that the Let’s Encrypt certificate is real, and it’s also working fine for other uses (website)
      • gnutls-cli reports that the certificate I installed for taskd is actually valid (it contains the whole chain)
      • pbecking1
        Yes, LE is real, but we have not got them working. One person did, but didn't tell us how.
      • polettix
        oh well this is easy, I can tell you how (although I consider this a workaround)!
      • pbecking1
        Please do.
      • polettix
        bottom line is this: when the automation script downloads a new certificate, it’s a file with two certificates inside
      • first one is *yours*, second one is the CA intermediate
      • you have to put the whole file as the certificate on the server side
      • and take only the second part of that file, put in a file and set is as the CA in the client side
      • ideally, you should only do the first action, the one on the client side is the workaround I was talking about
      • pbecking1
        Agreed.
      • polettix
        I can post a more structured example in a gist if you want
      • pbecking1
        That would be ideal. Thank you.
      • Q: "automoation script" <-- is that an LE thing?
      • polettix
        yes
      • LE gives you certificates that last no more than 90 days
      • it’s meant to be a low number of days to encourage automation
      • so there are a few scripts that you can setup and forget in the crontab
      • which also means that when the update happens, you have to figure out how to tell taskd to read it again
      • I tried sending SIGHUP but it didn’t work, so I just restart it
      • once in 90 days is not ideal but not bad either
      • gorgabal has quit
      • I hope it’s clear enough
      • I wonder why the trouble of installing the CA on the client side though… gnutls-cli says that the certificate is valid because it recognises that there is a valid chain in the file, but somehow task does not follow the same logic
      • vodka_ joined the channel
      • pbecking1
        polettix: Thanks, that's great.
      • My understanding is that every cert must chain all the way back to a a real or self-generated CA to be valid. Nothing else is valid.
      • polettix
        sure, but the certs generated by LE chain to a real one. This is why gnutls-cli and all browsers I used are fine with my LE certificate.
      • I’ll try to look into the code to figure this out
      • pbecking1
        polettix: I agree, LE certs are real and already point to a CA, thereby not requiring one on the client. Theoretically.
      • polettix
        I’ll try to play with the TLSClient and see what happens
      • pbecking1
        Nice
      • regagain has quit
      • vodka_ joined the channel
      • regagain joined the channel
      • tls2000 has quit
      • lindenk joined the channel
      • lindenk
        So, I'm having problems setting up the encryption on a taskd server. I followed the tutorial and generated my certs using the tool in the git repo for both a client and server (off of the same self-signed ca) and I'm getting the error "Error: Handshake failed. Error in the certificate." on the taskd server, and "Handshake failed. The TLS connection was non-properly terminated" on the client
      • I set the 'vars' file up with the hostname of the server, although one possible problem could be because I needed to set the 'server' option for taskd to it's internal IP on it's network, rather than the domain name
      • pbecking1
        lindenk: The setup guide needs careful attention to detail. Here is the setup guid you should follow: https://git.tasktools.org/projects/ST/repos/gui...
      • Here is the troubleshooting guide: https://git.tasktools.org/projects/ST/repos/gui...
      • lindenk: Follow the instructions, don't get creative.
      • vodka_ joined the channel
      • vodka joined the channel
      • lindenk
        er, ok so it looks like the problem is that the cert doesn't match the hostname of the server, however the server is on a separate network and I need it to bind to a local address
      • the client wouldn't be able to reach it by the same name otherwise
      • vodka_ has quit
      • polettix has quit
      • polettix joined the channel
      • flavius joined the channel
      • nolash joined the channel
      • pbecking1 has quit
      • pbecking1 joined the channel
      • pbecking1 has quit
      • pbecking1 joined the channel
      • polettix
        pbecking1: https://bug.tasktools.org/browse/TW-1855?filter=-2 has a patch for enabling auto-loading of CA files shipped by GnuTLS
      • it’s quite trivial, just a call to a function that was added as of GnuTLS 3.0.20
      • clients compiled against older versions will have to resort to the instructions I posted earlier
      • kidanger has quit
      • pbecking1
        polettix: Thanks, will take a look alter.
      • later
      • jrabbit
        wait did we acquire a tls expert
      • jrabbit gives polettix a gold star
      • oh not an expert but explorer of certs good enough
      • pbecking1
        jrabbit: Yes, we managed to trap one who was passing through.
      • jrabbit
        !m pbecking1
      • [b__b]
        You're doing good work, pbecking1!
      • regagain has quit
      • viq joined the channel
      • regagain joined the channel
      • dtzWill joined the channel
      • polettix has quit
      • pbecking1 has quit
      • pbecking1 joined the channel
      • regagain has quit
      • pbecking1 has quit
      • seschwar has quit
      • pbecking1 joined the channel
      • nolash has quit
      • nolash joined the channel