If people like the program, it comes with the library, too.
It's 8600 lines of code, MIT-licensed, and can do more than HTTP:
http://w3.impa.br/~diego/software/luasocket/reference.html
sure, I could parse that part...
Date:Wed, 12 Jul 2017 11:52:09 +
From:m...@netbsd.org
Message-ID: <20170712115209.ga7...@homeworld.netbsd.org>
| Yeah, didn't want to figure out how to point base lua into pkgsrc
| lua libraries.
It would not help if you did, it isn't the directory where the c
On Wed, Jul 12, 2017 at 06:42:57PM +0700, Robert Elz wrote:
> Whether it works or not (I have no current means to test it either)
> parrt of the issue is that it needs to work using only what is available
> in NetBSD release - so starting with #!/usr/pkg/bin/lua5.2 is not a good
> sign!
>
Yeah, d
Whether it works or not (I have no current means to test it either)
parrt of the issue is that it needs to work using only what is available
in NetBSD release - so starting with #!/usr/pkg/bin/lua5.2 is not a good
sign!
Beyond that:
-- assumes the fields are called 'username' and 'passwor
> I can create a simple CLI tool for it, but I won't be able to manage
> ones that require heavy use of javascript or captchas. Is anyone's
> captive portal requiring that?
>
> I would like examples (wget -r, please) of captive portals.
With the one I wrote, you simply need to do a HTTP Basic Auth
On Tue, Jul 11, 2017 at 10:31:59PM -0400, Thor Lancelot Simon wrote:
> Captive-portal login is a very real problem. How best to solve it otherwise?
> Remember, small embedded systems (easily supported by adding additional sets
> using our existing framework) are within scope.
If anyone wants to t
On Tue, Jul 11, 2017 at 10:31:59PM -0400, Thor Lancelot Simon wrote:
> Captive-portal login is a very real problem. How best to solve it otherwise?
> Remember, small embedded systems (easily supported by adding additional sets
> using our existing framework) are within scope.
I can create a simpl
On Wed, Jul 12, 2017 at 01:18:55AM +, m...@netbsd.org wrote:
> To reply to your points:
>
> - Debian doesn't ship ifconfig because it considers it a legacy tool and
> expects you to use 'ip'.
Yes, and they don't ship "netstat" because they expect you to use "ss",
and they don't ship (insert
To reply to your points:
- Debian doesn't ship ifconfig because it considers it a legacy tool and
expects you to use 'ip'.
- We already have a package tool.
Do you think pkg_* are doing poorly on file ownership? I don't intend
to port apt-get.
- I assume the open coding of file ownership is
t...@panix.com (Thor Lancelot Simon) writes:
>I believe the right solution to the real problem here is, and always has
>been, syspkg. I think it's truly regrettable how we never finished the
>work and it basically bitrotted. It's not clear to me how much effort
>would be required to
FreeBSD no
On Thu, Jul 06, 2017 at 01:18:44PM +, m...@netbsd.org wrote:
> I don't like such changes because I think netbsd's base is bad at
> handling software.
I disagree. With NetBSD's base system I get a consistent, fairly
complete traditional Unix system. I find it comfortable and easy
to use -- un
I don't like such changes because I think netbsd's base is bad at
handling software. it bunches a pile of unrelated things in a single
tarball, garbage collection is done with a 2600 line shell script, and
adding just a single file requires me to add an entry to a set list
that requires a full rele
On 07/04/17 19:58, Alistair Crooks wrote:
[---]
> I think we're all aware of the nature of trust wrt these certs. So
> quite why everyone is shouting "THESE CERTS MIGHT BECOME STALE OR
> UNTRUSTED, SO IT IS FAR BETTER TO CONTINUE TO TRUST EVERYTHING" is a
> bit beyond me.
[---]
You can't claim
> There are other stories as well, but that's a good illustration of
> why it's a bad idea to just hand over a bunch of CA's to users without
> any mechanism for keeping the CA database, and CRL's, up to date.
I expected this argument, but it is finally irrelevant. This is because most
users d
Thanks to Bennie for starting off this discussion. My apologies for
derailing things with the tzdata allusion.
I think we're all aware of the nature of trust wrt these certs. So
quite why everyone is shouting "THESE CERTS MIGHT BECOME STALE OR
UNTRUSTED, SO IT IS FAR BETTER TO CONTINUE TO TRUST EV
On 07/06/17 02:04, Alistair Crooks wrote:
> Distributing mozilla root certs is hardly "TNF takes on the role of a
> trusted CA source".
Granted, I'm a biased because of $dayjob, but in my view someone
handing me a bunch of CA certificates as part of an installation is by
definition taking on th
Distributing mozilla root certs is hardly "TNF takes on the role of a
trusted CA source".
And we need to start thinking laterally here. Certs are necessarily
transitory, and we wish any form of added trust to be enduring over a
period of time.
+ Can we use ssh fingerprints of project machines as
On Wed, 5 Jul 2017, Pierre Pronchery wrote:
Here's a thing: most users do not have the tiniest clue that there is such a
thing as SSL, even less X.509, certificates or authorities for that matter.
Maybe on Ubuntu, but I kind of think the bar for entry is a little
higher for BSD.
--
Hisashi T
Hi everyone,
On 04/07/2017 23:02, Jan Danielsson wrote:
On 07/04/17 21:15, Benny Siegert wrote:
There are other stories as well, but that's a good illustration of
why it's a bad idea to just hand over a bunch of CA's to users without
any mechanism for keeping the CA da
On 07/04/17 21:15, Benny Siegert wrote:
>> There are other stories as well, but that's a good illustration of
>> why it's a bad idea to just hand over a bunch of CA's to users without
>> any mechanism for keeping the CA database, and CRL's, up to date.
>
> I expected this argument, but it is fin
Benny Siegert writes:
> The question of root certificates for OpenSSL in base came up recently
> in pkgsrc. That got me thinking: why does NetBSD not come with a set
> of certificates in the base system? The set that mozilla-rootcerts
> delivers would be a reasonable thing to put there, because
On 07/03/17 03:01, David Holland wrote:
> On Mon, Jul 03, 2017 at 12:56:38AM +, Emmanuel Dreyfus wrote:
> > On Mon, Jul 03, 2017 at 12:45:17AM +0200, Joerg Sonnenberger wrote:
> > > The only problem I see is that outdated timezone data doesn't
> > > necessarily have a real world impact. Outd
On Mon, Jul 03, 2017 at 12:56:38AM +, Emmanuel Dreyfus wrote:
> On Mon, Jul 03, 2017 at 12:45:17AM +0200, Joerg Sonnenberger wrote:
> > The only problem I see is that outdated timezone data doesn't
> > necessarily have a real world impact. Outdated root CAs can.
>
> Most of the time, outd
On Mon, Jul 03, 2017 at 12:45:17AM +0200, Joerg Sonnenberger wrote:
> The only problem I see is that outdated timezone data doesn't
> necessarily have a real world impact. Outdated root CAs can.
Most of the time, outdated things in a system is dangerous. Known
security vulnearbilities accumulate
On Sun, Jul 02, 2017 at 05:27:06PM +0100, Benny Siegert wrote:
> agc made the argument that including certificates is similar to
> including time zone data, which we do. We do not tell users to install
> a package to use non-UTC timezones, for instance.
The only problem I see is that outdated time
The question of root certificates for OpenSSL in base came up recently in
pkgsrc. That got me thinking: why does NetBSD not come with a set of
certificates in the base system? The set that mozilla-rootcerts delivers would
be a reasonable thing to put there, because
(a) that’s what literally eve
26 matches
Mail list logo
