From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: [PATCH 2/2] services: Add tlsdate-service. Date: Thu, 08 Dec 2016 22:29:27 -0800 Message-ID: <87inqtsji0.fsf@gmail.com> References: <877f7emdzn.fsf@we.make.ritual.n0.is> <20161205183101.5937-1-ng0@libertad.pw> <20161205183101.5937-3-ng0@libertad.pw> <87k2bctdg0.fsf@gmail.com> <87twagc5dl.fsf@we.make.ritual.n0.is> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37947) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cFEhZ-0002A4-Ay for guix-devel@gnu.org; Fri, 09 Dec 2016 01:30:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cFEhW-0001ua-3Z for guix-devel@gnu.org; Fri, 09 Dec 2016 01:30:37 -0500 Received: from mail-pf0-f196.google.com ([209.85.192.196]:36126) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cFEhV-0001uO-TV for guix-devel@gnu.org; Fri, 09 Dec 2016 01:30:34 -0500 Received: by mail-pf0-f196.google.com with SMTP id c4so637539pfb.3 for ; Thu, 08 Dec 2016 22:30:33 -0800 (PST) In-Reply-To: <87twagc5dl.fsf@we.make.ritual.n0.is> (ng0@libertad.pw's message of "Wed, 07 Dec 2016 12:04:22 +0000") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: ng0 Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable ng0 writes: > The problem is, it defaults to google.com if we leave it > blank. I think this can be patched in the config it comes > with. But then again you could argue that so many people use > google that not using google and differing from the default would > make it obvious? I don't know much about tlsdate at the moment, > but I'm sure Jacob had an opinion and reasons why google.com was > picked. I see. I'd say just use the default that comes with the package. If a user needs to update it to something else, they probably know what they're doing and whom they trust. >> Is this really a daemon? It looks like we're just invoking a command >> which runs once at boot, but perhaps I'm mistaken. > > No, you are correct. I wanted to check out how the reaction and > feedback towards a one-time service at boot were, but I'll take > the feedback at the bottom of this message and switch back to the > tlsdated, which has some problems and isn't as easy as tlsdate. I'm not 100% certain that "run a command once at boot (every time we boot)" is bad, but I do think that if we can use the daemon instead, it is obviously a better fit for the "service" model. > Adding to what I replied the first time you asked this, let's be > consistent and say just TLS. Cool. I don't know much about tlsdate, though. If in fact it is getting the timestamp from TCP, then the word "TCP" seems correct. However, based on what I've read [1], tcpdate gets the time from the TLS handshake [1], so "TLS" seems correct to me. > I don't think that a time service which just runs once will be an > issue, but I'd like to be proven wrong. You're probably right about this. I think I may have overreacted. I think that practically speaking, a "service" which just runs tlsdate once at boot (every time we boot) is a little ugly (because it's a stretch to say that it's a "service"), but it's not bad. However, I do still think that tlsdated is the natural fit for the "service" model, since it is a daemon, and tlsdate is not. So why not use it? I agree: I think the problem David and I were discussing earlier in IRC is different, and uglier. For details, please refer to the IRC log. > If our issue tracker would already be public I could link you to > more specific reasons and discussion, but so far: just assume I'm > building a system around/integrated into GuixSD which after core > (phase one) targets piece by piece to eliminate the need to fetch > information through the old internet and rather use gnunet for > those tasks. That's not easy to achieve (not in a very short > time), but this tlsdate is an intermediate solution. Sounds cool! > ** > There's an related issue: > Every service I currently work on absolutely requires network to > be tested (well except `psyced` which can cope fine just > locally), would the qemu be able to talk to outside if I created > an network bridge? Or is there more to be added? I know I had > this dicussion in the past but obviously it did not work for me > as I'm still sitting on an 90% finished 'in theory it works' > gnunet service for guix. > ** There are many ways to launch a qemu virtual machine. If you use "the right" combination of options, your guest will be able send IP packets to other hosts on the Internet. I'd be happy to help troubleshoot whatever problems you're having - if you're interested, please contact me privately (or start a new email thread) so we don't derail this email thread. =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlhKT0cACgkQ3UCaFdgi Rp0WPQ/9H/uSBA/xkuUjTKzkYI//RuTT2jJ6GypEAgO0jrNlEw5OdU0ZQkrKjW1F DeVAdDZ+IxN1jVRZKnyXFbavudlPZDgoglvz+nfIQNQm2fcBGTzcMnNFTlKK94XP IMMcnej2OhmWG1JJ9qxCsOrfAlcfB40c3s8Y/YuNowlAkDJjqIoS0sI6bxP0l2Z+ FikvYD/dtmyKN3roY/w0E0uS2BDGHUKZRyoOca8oaoAZu2BJpSxGxIpTLitGWdz5 y/NaWDwT+BkAFKrXLDdd/5MAqVjOvEfhsS1/wNSvPyQi3ZYK5xazjE4hqRtDA10o TD46fIdCt1MSaaCgzjVp1w+sBEX15kLz9VhvdBFc+p+UFVhqSovqVFbPyehkhxQD pulqe3ZETk7YBK/uXdLw57BLAwYHstodd0TLmgRi6c8U4B0JhDcabOz/6Vr1j0Y9 utfjNTC4/V3HKfV0IAxjJSAtQblmBBX8qm5MJ3tcTzPdPuesAoH4qdVyDO35rZ8m yiK5cPFsu4GM3kXszxqfX1VwsNba9PNPDY4ndOsZgx4Fac3IJepz5thYRyJWjsi5 LDuraC0l0qMcUwwKw2aroCIfLOf32zV8cIMzPuVH6xYtlhHDoZGFSNOqud8aNF2T 8Y7OoZnAPF//rYlqSFvFU8XprtIWlTt3SCvPyzzZAqI+SQx625M= =bsUk -----END PGP SIGNATURE----- --=-=-=--