On 11/6/22 15:29, Job Snijders wrote:
Dear all,
Support for using Ed25519 for server and user authentication was
introduced in 2014. I like the compactness of Ed25519 public keys.
Perhaps now is a good time to make Ed25519 the default key type when
invoking ssh-keygen(1) without arguments?
K
On 10/11/22 13:10, bug wrote:
On Mon, Oct 10, 2022 at 11:17:32AM -0600, Theo de Raadt wrote:
It's been explained a few times that being up-to-date is not an error.
It's a good thing, and no action is neccessary when up-to-date.
Any non-zero value indicates an error, that would include 2. You
On 1/16/19 19:09, Otto Moerbeek wrote:
On Wed, Jan 16, 2019 at 01:25:25PM +, Stuart Henderson wrote:
On 2019/01/04 08:09, Otto Moerbeek wrote:
On Thu, Dec 27, 2018 at 09:39:56AM +0100, Otto Moerbeek wrote:
Very little feedback so far. This diff can only give me valid feedback
if the cov
On 3/17/21 11:02 AM, Stuart Henderson wrote:
On 2021/03/17 10:53, Jan Klemkow wrote:
ping
On Tue, Mar 09, 2021 at 03:49:32PM +0100, Jan Klemkow wrote:
Hi,
The verification of the https://ugos.ugm.ac.id certificate contains 2032
subject alt names which leads to the following error in LibreSS
On 12/16/20 11:13 AM, Janne Johansson wrote:
Den ons 16 dec. 2020 kl 10:42 skrev Renaud Allard <mailto:ren...@allard.it>>:
> While there, I propose to change the proposed crontab to once a day
> instead of every hour. The certificates can be renewed 1 full mont
On 12/16/20 9:44 AM, Solene Rapenne wrote:
On Tue, 15 Dec 2020 10:18:41 +0100
Solene Rapenne :
This is a small change to acme-client(1) because I find
the explanation of -F flag not being obvious that you
need it when you add/remove an alternative name in your
domain config.
Maybe wording co
On 11/27/20 1:29 PM, Stuart Henderson wrote:
It's not very clear how to fetch the pubkey. OK to add this to wg(4)?
Index: wg.4
===
RCS file: /cvs/src/share/man/man4/wg.4,v
retrieving revision 1.6
diff -u -p -r1.6 wg.4
--- wg.4
On 10/10/2020 22:05, Stuart Henderson wrote:
Here's an update to the recently released version of Unbound. Much of
the additional code is for DoH and is unused here as it requires the
nghttp2 library.
nghttp2 seems to be MIT licensed. Could it be possible to import it in base?
smime.p7s
D
On 23/04/2020 16:18, Todd C. Miller wrote:
On Thu, 23 Apr 2020 14:40:15 +0200, Denis Fondras wrote:
I don't know if it is useful to anyone else but it is required by lsquic, a
library that implements QUIC / HTTP3.
sniproxy port also uses STAILQ_*, there is a patch in the port for the
imp
On 4/7/20 6:05 PM, Stuart Henderson wrote:
fwiw my usual approach is to put /var/www on a separate filesystem ..
I do generally create a separate filesystem for /var/www/tmp (and
/var/www). But I feel this is the responsibility of whoever installs
stuff which will write in this directory t
On 3/19/20 10:36 AM, Stuart Henderson wrote:
On 2020/03/19 09:27, Renaud Allard wrote:
After some days of testing I didn't see any real problem with that diff.
It's working as expected.
Also, I found out that putting "so-reuseport: no" completely stops all the
stalling
On 3/15/20 9:53 PM, Stuart Henderson wrote:
On 2020/03/15 19:05, Renaud Allard wrote:
On 15/03/2020 17:36, Stuart Henderson wrote:
Lots of churn again.. most of the new + are related to the new rpz and
serve-stale support. I've been running it for a few days with my usual
setup wi
On 3/16/20 10:54 PM, Jordan Geoghegan wrote:
That's good to hear, I've had a number of issues with DoT stalling on
1.9.4 and 1.9.6. I've found having multiple entries in my forwarders
section has somewhat mitigated the issue. I wonder if the stalling
problem is related to this:
https://git
On 3/15/20 9:53 PM, Stuart Henderson wrote:
On 2020/03/15 19:05, Renaud Allard wrote:
On 15/03/2020 17:36, Stuart Henderson wrote:
Lots of churn again.. most of the new + are related to the new rpz and
serve-stale support. I've been running it for a few days with my usual
setup wi
On 15/03/2020 17:36, Stuart Henderson wrote:
Lots of churn again.. most of the new + are related to the new rpz and
serve-stale support. I've been running it for a few days with my usual
setup with no problems, haven't tried the new things yet. Anyone want
to test?
I have had a lot of stalli
On 22/11/2019 16:38, Craig Skinner wrote:
On Tue, 19 Nov 2019 10:35:56 + Stuart Henderson wrote:
We are short on partitions, there is a hard limit (14+swap), disklabel auto
defaults already use 9, and there need to be some free for typical user use
(ports, dest for "make release", people o
On 11/20/19 12:06 PM, Solene Rapenne wrote:
On Tue, Nov 12, 2019 at 07:02:56PM +0100, Renaud Allard wrote:
On 12/11/2019 08:29, Theo de Raadt wrote:
Renaud, please test it for me like this:
sysupgrade -d /
This interface is dangerously incorrect.
What about this one?
Index
On 11/20/19 10:59 AM, Solene Rapenne wrote:
no, this script makes /home/_sysupgrade a symbolic link to the real
location where you want to store the sets. So /home doesn't require more
space than the requirement for an additional symlink.
sysupgrade has a check to ensure the directory is n
Hi Solene,
On 11/20/19 10:46 AM, Solene Rapenne wrote:
wouldn't be easier for people using non standard locations to write a
small wrapper script like this (not tested, written in the mail)
#!/bin/sh
MYDEST=/var/sysupgrade
install -d -o root -g wheel $MYDEST
rm -fr /home/_sysupgrade
ln -s $MY
On 11/19/19 11:11 AM, Craig Skinner wrote:
If the installer created a 750Mb /var/cache/ partition, and sysupgrade's cache
directory is hard coded as /var/cache/sysupgrade/, would that simply solve
the various problems people are having & scripting difficulties?
Other tools which cache files
On 11/19/19 10:00 AM, Stuart Henderson wrote:
It does avoid the removal issue but it seems an awkward user interface to
pass the parent directory. Perhaps better to enforce that the path matches
*/_sysupgrade, though this also doesn't feel quite right. Perhaps add
/_sysupgrade if it wasn't alre
On 11/18/19 10:08 AM, Raimo Niskanen wrote:
A configuration parameter could be accomplished through an optional symlink
/etc/_sysupgrade that the sysadmin can create to point at the installation's
sysupgrade directory. The sysupgrade script would test -s /etc/_sysupgrade
and if there is a sym
On 11/13/19 11:51 PM, Renaud Allard wrote:
On 12/11/2019 19:02, Renaud Allard wrote:
On 12/11/2019 08:29, Theo de Raadt wrote:
Renaud, please test it for me like this:
sysupgrade -d /
This interface is dangerously incorrect.
What about this one?
ping.
I haven't see
On 12/11/2019 19:02, Renaud Allard wrote:
On 12/11/2019 08:29, Theo de Raadt wrote:
Renaud, please test it for me like this:
sysupgrade -d /
This interface is dangerously incorrect.
What about this one?
ping.
I haven't seen any reply on the prefix based patch, but what
On 12/11/2019 08:29, Theo de Raadt wrote:
Renaud, please test it for me like this:
sysupgrade -d /
This interface is dangerously incorrect.
What about this one?
Index: sysupgrade.8
===
RCS file: /cvs/src/usr.sbin/sysupg
On 11/12/19 8:29 AM, Theo de Raadt wrote:
Renaud Allard wrote:
+.It Fl d Ar directory
+Choose the
+.Ar directory
+in which the sets will be downloaded.
+Default is
+.Pa /home/_sysupgrade .
...
+ d) SETSDIR=${OPTARG};;
...
-rm -f /home/_sysupgrade/{${CLEAN}}
+rm -f
On 09/11/2019 12:52, Klemens Nanni wrote:
On Fri, Nov 08, 2019 at 11:59:20AM +, Stuart Henderson wrote:
Given the amount of people which encrypt /home directory on their servers,
it might be useful to be able to define another directory for the sets in
sysupgrade as /home_sysupgrade will n
Hello,
Given the amount of people which encrypt /home directory on their
servers, it might be useful to be able to define another directory for
the sets in sysupgrade as /home_sysupgrade will not be available in that
case.
Here is a patch for this.
Regards
Index: sysupgrade.8
===
Hello,
I saw the subject over disabling by default DoH on firefox, which is a
great idea.
But in the same vein, shouldn't we enable qname-minimisation in unbound
by default?
Regards
smime.p7s
Description: S/MIME Cryptographic Signature
On 6/17/19 3:33 PM, Theo Buehler wrote:
On Mon, Jun 17, 2019 at 01:44:47PM +0200, Renaud Allard wrote:
Hello,
EVP_MD_CTX_create(), EVP_MD_CTX_cleanup(), and EVP_MD_CTX_destroy() are
deprecated aliases for EVP_MD_CTX_new(), EVP_MD_CTX_reset(), and
EVP_MD_CTX_free(). So replace the occurrences
On 6/17/19 2:58 PM, Florian Obser wrote:
What would be the correct calculation for a GF2m field? Should I maybe just
ignore it? RFC 7518 only lists P-256, P-384 and P-521 (and I think
Let's Encrypt only supports P-384 anyway), and they are all GFp, no?
Let's Encrypt accepts P-256 and P-384 EC
Hello,
EVP_MD_CTX_create(), EVP_MD_CTX_cleanup(), and EVP_MD_CTX_destroy() are
deprecated aliases for EVP_MD_CTX_new(), EVP_MD_CTX_reset(), and
EVP_MD_CTX_free(). So replace the occurrences to be future proof.
Comments?
Index: acctproc.c
===
On 6/14/19 1:58 PM, Florian Obser wrote:
On Fri, Jun 14, 2019 at 09:50:35AM +0200, Renaud Allard wrote:
On 6/12/19 2:30 PM, Renaud Allard wrote:
On 6/11/19 2:36 PM, Sebastian Benoit wrote:
Hi,
some feedback below.
Renaud: maybe wait for feedback from florian or gilles until
acting on
On 6/12/19 2:30 PM, Renaud Allard wrote:
On 6/11/19 2:36 PM, Sebastian Benoit wrote:
Hi,
some feedback below.
Renaud: maybe wait for feedback from florian or gilles until
acting on my comments, sometimes sending diffs to fast creates more
work ;)
/Benno
As suggested by benno
On 6/11/19 2:36 PM, Sebastian Benoit wrote:
Hi,
some feedback below.
Renaud: maybe wait for feedback from florian or gilles until
acting on my comments, sometimes sending diffs to fast creates more work ;)
/Benno
As suggested by benno@
removal of the global variable
removal of KEYTYPE wh
On 6/11/19 10:17 AM, Renaud Allard wrote:
Hello,
Here is a patch with ecdsa and rsa in %token after the domain key name
OK? comments?
I just made a small modification in the formatting of acme.conf man
page, putting keytype as an arg. And also a cleaner key.h
OK?
Index: Makefile
On 6/7/19 2:38 PM, Renaud Allard wrote:
On 6/7/19 2:28 PM, Florian Obser wrote:
On Fri, Jun 07, 2019 at 10:40:36AM +0200, Renaud Allard wrote:
On 6/6/19 10:46 AM, Renaud Allard wrote:
On 6/6/19 10:10 AM, Florian Obser wrote:
I currently don't have time to review this. I&#
On 6/7/19 2:28 PM, Florian Obser wrote:
On Fri, Jun 07, 2019 at 10:40:36AM +0200, Renaud Allard wrote:
On 6/6/19 10:46 AM, Renaud Allard wrote:
On 6/6/19 10:10 AM, Florian Obser wrote:
I currently don't have time to review this. I'm busy switching
acme-client to th
On 6/7/19 2:28 PM, Florian Obser wrote:
On Fri, Jun 07, 2019 at 10:40:36AM +0200, Renaud Allard wrote:
On 6/6/19 10:46 AM, Renaud Allard wrote:
On 6/6/19 10:10 AM, Florian Obser wrote:
I currently don't have time to review this. I'm busy switching
acme-client to th
On 6/7/19 10:40 AM, Renaud Allard wrote:
On 6/6/19 10:46 AM, Renaud Allard wrote:
On 6/6/19 10:10 AM, Florian Obser wrote:
I currently don't have time to review this. I'm busy switching
acme-client to the rfc 8555 / letsencrypt v2 api. Doesn't look like
this conflicts to
On 6/6/19 10:46 AM, Renaud Allard wrote:
On 6/6/19 10:10 AM, Florian Obser wrote:
I currently don't have time to review this. I'm busy switching
acme-client to the rfc 8555 / letsencrypt v2 api. Doesn't look like
this conflicts too badly with my work, but I'd appreciate
On 6/6/19 4:02 PM, Florian Obser wrote:
This switches acme-client(1) from draft-03 to the final standard.
Let's Encrypt claims - and this seems to be true in my testing - that
accounts created on the v01 api (the draf one) work on the v02 api
(rfc).
This drops support for v01, thinks got shuf
On 6/6/19 10:10 AM, Florian Obser wrote:
On Wed, Jun 05, 2019 at 05:37:51PM +0200, Gilles Chehade wrote:
On Wed, Jun 05, 2019 at 08:39:51AM +0200, Renaud Allard wrote:
On 6/5/19 8:20 AM, Gilles Chehade wrote:
On Tue, Jun 04, 2019 at 03:54:11PM +0200, Renaud Allard wrote:
On 6/3/19 11
On 6/5/19 8:39 AM, Renaud Allard wrote:
On 6/5/19 8:20 AM, Gilles Chehade wrote:
On Tue, Jun 04, 2019 at 03:54:11PM +0200, Renaud Allard wrote:
On 6/3/19 11:53 AM, Renaud Allard wrote:
On 5/29/19 9:58 AM, Florian Obser wrote:
why not let acme-client generate the key?
Here is a
On 6/5/19 8:20 AM, Gilles Chehade wrote:
On Tue, Jun 04, 2019 at 03:54:11PM +0200, Renaud Allard wrote:
On 6/3/19 11:53 AM, Renaud Allard wrote:
On 5/29/19 9:58 AM, Florian Obser wrote:
why not let acme-client generate the key?
Here is a more complete diff where you can use the -E
On 6/3/19 11:53 AM, Renaud Allard wrote:
On 5/29/19 9:58 AM, Florian Obser wrote:
On Wed, May 22, 2019 at 01:33:11PM +0200, Renaud Allard wrote:
The key needs to be generated manually
i.e.: openssl ecparam -genkey -name secp384r1 -out privkey.pem
why not let acme-client generate the key
On 6/3/19 11:18 AM, Renaud Allard wrote:
On 5/29/19 10:19 AM, Renaud Allard wrote:
On 5/29/19 9:58 AM, Florian Obser wrote:
On Wed, May 22, 2019 at 01:33:11PM +0200, Renaud Allard wrote:
The key needs to be generated manually
i.e.: openssl ecparam -genkey -name secp384r1 -out
On 5/29/19 10:19 AM, Renaud Allard wrote:
On 5/29/19 9:58 AM, Florian Obser wrote:
On Wed, May 22, 2019 at 01:33:11PM +0200, Renaud Allard wrote:
The key needs to be generated manually
i.e.: openssl ecparam -genkey -name secp384r1 -out privkey.pem
why not let acme-client generate the key
On 5/29/19 9:58 AM, Florian Obser wrote:
On Wed, May 22, 2019 at 01:33:11PM +0200, Renaud Allard wrote:
Hello,
First, sorry for double posting to misc@.
This is a short patch to let acme-client accept ECDSA keys now that
letsencrypt accepts signing certificates with those keys. This
Hello,
I had some problems connecting to my SSL enabled pure-ftpd server with
filezilla 3.42 (on windows) which uses GnuTLS 3.6.7. I am running
OpenBSD 6.5.
I opened a thread on filezilla forum and the developer claims this is
due to a bug in LibreSSL.
The thread is here:
https://forum.file
Hello,
First, sorry for double posting to misc@.
This is a short patch to let acme-client accept ECDSA keys now that
letsencrypt accepts signing certificates with those keys. This
functionality is present in certbot, so it might be a good idea to let
acme-client accept that too.
The key need
On 01/13/2016 06:10 AM, Theo de Raadt wrote:
$ fgrep constraint /etc/ntpd.conf
constraints from "https://www.google.com";
$
www.google.com and other Google services are not accessible from
countries like China or Vietnam. It's easy enough for people to
change their ntpd.conf if necessary but ho
Hello,
Here is a small patch to add the USB-AC56 from Asus to usbdevs
ID 0b05:17d2 ASUSTek Computer, Inc.
dmesg gives a somewhat misleading name:
ugen0 at uhub2 port 6 "Realtek 802.11n NIC" rev 2.00/0.00 addr 5
I know that chipset is not supported yet, so do what you think is best.
Index: usbd
On 27/08/15 21:18, Ted Unangst wrote:
Renaud Allard wrote:
I understand the difference, but we are opposed to adding new options unless a
majority of users are expected to use them.
OK, I can understand. However, it doesn't do anything normal auth can't
do, except giving the use
On 27/08/15 19:30, Theo de Raadt wrote:
security model.
How many users of that functionality will there be?
We only need to concern ourselves with the cost; you have to justify
the benefit. How many people were doing this with sudo, and how many
will need this with doas?
While I understan
On 27/08/15 19:08, Theo de Raadt wrote:
doas is a one of the few setuid programs. It should try to do a
little bit less functionality, because "doing less" is part of the
security model.
How many users of that functionality will there be?
We only need to concern ourselves with the cost; you
On 27/08/15 18:32, Ted Unangst wrote:
Sorry, I think adding an option is too much. I just committed halex's original
diff to only change the type. I thought he was going to do that by now.
Hi Ted,
The thing is, my patch doesn't do the same thing at all as the one which
adds auth-doas. My
On 08/26/2015 06:39 PM, Michael Reed wrote:
Hi Renauld,
On 08/26/15 09:38, Renaud Allard wrote:
I rewrote a little bit the patch to remove a small kind-of typo in the manpage
and remove too long lines.
So with this patch, you add the user the right to choose the authentication
style and
I rewrote a little bit the patch to remove a small kind-of typo in the
manpage and remove too long lines.
So with this patch, you add the user the right to choose the
authentication style and administratively, in login.conf, you can
restrict it.
Any comments? OK?
Index: doas.1
==
On 08/26/2015 09:36 AM, Renaud Allard wrote:
On 08/26/2015 09:26 AM, Gregor Best wrote:
On Wed, Aug 26, 2015 at 08:42:31AM +0200, Renaud Allard wrote:
[...]
+fprintf(stderr, "usage: doas [-ans] [-C config] [-u user] command
[args]\n");
[...]
The usage string should p
On 08/26/2015 09:26 AM, Gregor Best wrote:
On Wed, Aug 26, 2015 at 08:42:31AM +0200, Renaud Allard wrote:
[...]
+ fprintf(stderr, "usage: doas [-ans] [-C config] [-u user] command
[args]\n");
[...]
The usage string should probably be
"usage: doas [-ns] [-a style]
On 08/24/2015 03:47 PM, Renaud Allard wrote:
On 08/24/2015 11:15 AM, Renaud Allard wrote:
Hello,
Is there a plan to make it possible to specify the authentication type
in doas, like "sudo -a" does?
This is useful in the case you are using a login.conf with something
like: "aut
On 08/24/2015 11:15 AM, Renaud Allard wrote:
Hello,
Is there a plan to make it possible to specify the authentication type
in doas, like "sudo -a" does?
This is useful in the case you are using a login.conf with something
like: "auth-defaults:auth=yubikey,passwd;".
Regards
Hello,
Is there a plan to make it possible to specify the authentication type
in doas, like "sudo -a" does?
This is useful in the case you are using a login.conf with something
like: "auth-defaults:auth=yubikey,passwd;".
Regards
smime.p7s
Description: S/MIME Cryptographic Signature
On 02/10/2015 12:43 PM, Stuart Henderson wrote:
On 2015/02/10 12:32, Reyk Floeter wrote:
Let me share the answer to a question that I got in a private mail:
On Tue, Feb 10, 2015 at 10:55:53AM +0100, Reyk Floeter wrote:
---snip---
servers pool.ntp.org
constraints from "https://www.google.com/s
On 01/27/2015 08:26 AM, Renaud Allard wrote:
Hello,
I wrote a patch which adds a new kernel sysctl (hideproc) to hide
processes non owned by a user, except for root. This should be mostly
useful on shell servers and on servers with chroots.
I know some controversial patches have been presented
On 01/27/2015 09:07 AM, STeve Andre' wrote:
On 01/27/15 02:26, Renaud Allard wrote:
Hello,
I wrote a patch which adds a new kernel sysctl (hideproc) to hide
processes non owned by a user, except for root. This should be mostly
useful on shell servers and on servers with chroots.
I know
On 01/27/2015 09:07 AM, STeve Andre' wrote:
On 01/27/15 02:26, Renaud Allard wrote:
Hello,
I wrote a patch which adds a new kernel sysctl (hideproc) to hide
processes non owned by a user, except for root. This should be mostly
useful on shell servers and on servers with chroots.
I know
Hello,
I wrote a patch which adds a new kernel sysctl (hideproc) to hide
processes non owned by a user, except for root. This should be mostly
useful on shell servers and on servers with chroots.
I know some controversial patches have been presented in the past, but
this one only does only o
Hello,
Here is a small diff for pcidevs to add the NVIDIA GTX 650, including
its HDMI audio part.
Regards
--- sys/dev/pci/pcidevs.old Fri May 9 14:39:50 2014
+++ sys/dev/pci/pcidevs Fri May 9 14:39:26 2014
@@ -5507,6 +5507,8 @@
product NVIDIA MCP89_OHCI 0x0d9c MCP89 USB
product NVIDIA MCP
70 matches
Mail list logo
