Re: siginfo_t.si_addr should be void*
On 2016-05-30 08:59, Martin Pieuchot wrote:
On 27/04/16(Wed) 18:52, i80...@foxquill.com wrote:
On 2016-04-27 18:20, Joerg Sonnenberger wrote:
>This
>[...snip...]
>and this disagree?
I... am so sorry. You're right of course; I don't know how that patch
happened.
ok mpi@
Regenerated the patch with CVS, now that I actually know how to use it
a little bit:
Index: siginfo.h
===
RCS file: /var/storage/andrew/openbsd/cvs/src/sys/sys/siginfo.h,v
retrieving revision 1.11
diff -u -p -u -r1.11 siginfo.h
--- siginfo.h 14 Apr 2015 16:40:46 - 1.11
+++ siginfo.h 29 Mar 2017 22:17:49 -
@@ -150,7 +150,7 @@ typedef struct {
} _pdata;
} _proc;
struct {/* SIGSEGV, SIGBUS, SIGILL and SIGFPE */
- caddr_t _addr; /* faulting address */
+ void*_addr; /* faulting address */
int _trapno;/* illegal trap number */
} _fault;
#if 0
Thank you,
Andrew Aldridge
comsat: prefer pread() over lseek+read
...and open() only needs the mode argument if O_CREAT is present.
ok?
Index: libexec/comsat/comsat.c
===
RCS file: /cvs/src/libexec/comsat/comsat.c,v
retrieving revision 1.45
diff -u -p -r1.45 comsat.c
--- libexec/comsat/comsat.c 2 Apr 2016 16:33:28 - 1.45
+++ libexec/comsat/comsat.c 2 Apr 2017 00:39:51 -
@@ -100,7 +100,7 @@ main(int argc, char *argv[])
(void) recv(0, msgbuf, sizeof(msgbuf) - 1, 0);
exit(1);
}
- if ((uf = open(_PATH_UTMP, O_RDONLY, 0)) == -1) {
+ if ((uf = open(_PATH_UTMP, O_RDONLY)) == -1) {
syslog(LOG_ERR, "open: %s: %m", _PATH_UTMP);
(void) recv(0, msgbuf, sizeof(msgbuf) - 1, 0);
exit(1);
@@ -194,8 +194,7 @@ doreadutmp(void)
utmp = u;
utmpsize = nutmpsize;
}
- (void)lseek(uf, 0, SEEK_SET);
- nutmp = read(uf, utmp, statbf.st_size)/sizeof(struct utmp);
+ nutmp = pread(uf, utmp, statbf.st_size, 0)/sizeof(struct utmp);
dsyslog(LOG_DEBUG, "read %d utmp entries", nutmp);
}
(void)alarm(15);
Re: httpd/libtls: TLS client certificate revocation checking
On Sat, 01 Apr 2017 18:22:17 + Bob Beck wrote: > There will be some libtls api additions post 6.1 to get the peer cert > in PEM format Thanks Bob. That sounds like exactly what's needed. Happy to wait. > In the meantime, testing snaps prior to 6.1 should be the priority. > not a talkathon. Agreed. Sorry for the noise.
Re: httpd/libtls: TLS client certificate revocation checking
There will be some libtls api additions post 6.1 to get the peer cert in PEM format In the meantime, testing snaps prior to 6.1 should be the priority. not a talkathon. On Sat, Apr 1, 2017 at 10:49 Joerg Sonnenberger wrote: > On Sat, Apr 01, 2017 at 07:53:05PM +1030, Jack Burton wrote: > > One common example of that happening is when a cert gets revoked because > > its private key has been lost/stolen and the user needs a new cert > > associated with the same identity. An even more common example is when > > a cert expires & gets renewed. > > If you are using certificate revocation, I think you should do the check > as early as possible. That means in httpd in this case. Nothing later in > the stack should have to care about expired or revoked certificates -- > it just adds complexity and the danger of someone forgetting about it. > > Which mechanisms to support (i.e. CRLs or OCSP) is a completely > different topic. > > Joerg > >
Re: httpd/libtls: TLS client certificate revocation checking
On Sat, Apr 01, 2017 at 07:53:05PM +1030, Jack Burton wrote: > One common example of that happening is when a cert gets revoked because > its private key has been lost/stolen and the user needs a new cert > associated with the same identity. An even more common example is when > a cert expires & gets renewed. If you are using certificate revocation, I think you should do the check as early as possible. That means in httpd in this case. Nothing later in the stack should have to care about expired or revoked certificates -- it just adds complexity and the danger of someone forgetting about it. Which mechanisms to support (i.e. CRLs or OCSP) is a completely different topic. Joerg
Re: sync root.mail
Marc Espie writes: > On Thu, Mar 30, 2017 at 09:00:41PM +0200, Jeremie Courreges-Anglas wrote: >> Marc Espie writes: >> >> > On Wed, Mar 29, 2017 at 09:40:32PM +0200, Christian Weisgerber wrote: >> >> Antoine Jacoutot: >> >> >> >> > Why not just: >> >> > >> >> > # pkg_add -v rsync chromium emacs--no_x11 >> >> > >> >> > So we don't have to change it each release? >> >> >> >> Because people won't let Emacs 21 die. >> >> >> >> Ambiguous: choose package for emacs--no_x11 >> >> a 0: >> >> 1: emacs-21.4p37-no_x11 >> >> 2: emacs-25.1p3-no_x11 >> >> Your choice: >> > >> > pkg_add -v rsync chromium emacs--no_x11%emacs >> >> Omitting the version, adding a flavor and specifying a branch is a bit >> verbose IMHO. Like Antoine, I'd prefer if we stopped listing emacs >> here. > > Think about it. > > In one line, you explain to people how to do this kind of thing, so that > noobs get to figure out how to get to flavors and branches without specifying > version numbers. I would rather put this kind of example in faq15, but fine. > Is that a win or a loss ? If you think it's a win, please go ahead. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: httpd/libtls: TLS client certificate revocation checking
On Fri, 31 Mar 2017 22:21:38 +0200
Joerg Sonnenberger wrote:
> On Fri, Mar 31, 2017 at 01:03:44PM -0700, William Ahern wrote:
> > Basically, anything short of passing through the entire certificate
> > is going to be severely limiting and frustrating, to the point of
> > uselessness.
>
> Passing down the common name is normally enough, but not doing that
> makes it nearly useless. Speaking from the perspective of using them
> in the wild.
My initial diff passed the DN (from which you can get the CN with a
trivial regex) in TLS_PEER_SUBJECT.
That might be enough in some circumstances, but remember that RFC5280
tells us "A CA MAY issue more than one certificate with the same DN to
the same subject entity"...
One common example of that happening is when a cert gets revoked because
its private key has been lost/stolen and the user needs a new cert
associated with the same identity. An even more common example is when
a cert expires & gets renewed.
The only thing that's always required to be unique is {issuer,
serialNumber}.
So at a minimum the serialNumber & issuer are both still necessary for
unique identification (in addition to the DN plus whatever else for
authorisation)...
...unless you've *already* validated that the cert has not been revoked
(but either checking CRLs or doing non-stapled OCSP also requires
knowing the serialNumber).
In fact, your application's authorisation routines can be quite a bit
simpler if your CA adopts a policy of having a 1:1 mapping of entities
to DNs, varying only the serial number & valid date range when renewing
or revoking/reissuing certs -- but that's a matter of personal choice:
nothing wrong with a CA having a "DNs never get reused" rule, but I
don't think it's reasonable to expect *every* CA to do that, given that
RFC5280 explicitly allows DN reuse for the same entity.
I agree with you that it probably makes sense to continue passing the
DN, even if we pass the whole cert as well, so that fastcgi responders
with simple auth schemes using CAs that do implement a "DNs never get
reused" rule don't need to link against libcrypto just to get the DN,
but I don't think that's a reason to shy away from William's good
suggestion of passing the whole cert.
On the other hand the rest of the TLS_PEER_* fastcgi variables from my
initial diff can probably be left out if we're passing the whole cert
(e.g. if you have the cert it's easy enough to generate the hash
yourself).
Re: httpd/libtls: TLS client certificate revocation checking
On Fri, 31 Mar 2017 13:03:44 -0700 William Ahern wrote: > On Thu, Mar 30, 2017 at 10:31:06PM +1030, Jack Burton wrote: > > > Personally, I'm leaning towards either local CRL file checking in > > httpd (with minimal changes to libtls), or passing through enough > > data to the let the fastcgi responders take whichever approach they > > want. <...> > My $0.02: client certificates aren't particularly useful unless the > certificate itself is made available to the application. Knowing that > a certificate has a valid signature is only part of the equation, and > not even the most useful part. Unlike server certificates, however, > there's no single authorization check (i.e. matching the embedded > domain name to the queried URL) that can be implemented by > middle-ware. The semantics of embedded data are specific to a service > and often ad hoc. > > Basically, anything short of passing through the entire certificate > is going to be severely limiting and frustrating, to the point of > uselessness. And as a practical matter, parsing out and passing > through a subset of certificate data is likely going to require more > complex code than just passing the entire certificate to the > application. Thanks William. That's an interesting idea. Yes, I can see how having the raw client certificate available to fastcgi responders would be useful. That would solve a few more problems for my use case too and would provide the ultimate in flexibility. And it's not difficult to implement. My initial gut feeling was that adding a tls_peer_serial() function to libtls would be less intrusive (and more in keeping with the rest of the tls_peer_* functions) than adding a tls_peer_cert() along the lines you're suggesting. But on reflection, adding a tls_peer_cert() would drastically reduce the likelihood of needing to add anything else to the tls_peer_* family again in future -- which I'd think would be a big advantage. Given your point about needing to access the whole cert (I assume by that you mean you're using some of the less common x509 extensions) for authorisation (cf. just authentication), it may well be worth doing that *regardless* of whether or not any common approach to revocation status checking gets added that far down the stack. Unless there are any better ideas in the meantime (or someone else does it first), I'll propose a diff that does just that towards the end of next week (sorry, will travelling for the next few days & probably won't have time to site down & write it until then).
Re: Another arm64 pmap cleanup diff
On Sat, Apr 01, 2017 at 06:08:23PM +1100, Jonathan Gray wrote: > On Fri, Mar 31, 2017 at 02:03:37PM +0200, Mark Kettenis wrote: > > On ARMv8, the translation table walk is fully coherent so there is no > > reason to explicitly flush the cache before invalidating the TLB. The > > barrier that is included in out TLB flushing code should be enough to > > guarantee that the TLB walking hardware sees the updated page table > > contents, so the explicit barriers can go as well. Diff also > > sanitizes the code immediately around the removed bits of code to drop > > redundant curly braces, avoid C++ style comments and removes some > > blank lines that aren't particular useful. > > > > Can somebody give this a spin on hardware with a Cortex-A57 and verify > > that this doesn't make things more unstable? > > I didn't encounter any problems running a make build with this change. > It also slightly improved the build time: > > 291m24.74s real 257m59.41s user16m05.09s system > 286m32.07s real 255m44.31s user15m22.44s system > I wanted to see this tested, but given this testing, ok drahn@ Dale Rahn dr...@dalerahn.com
Re: Another arm64 pmap cleanup diff
On Fri, Mar 31, 2017 at 02:03:37PM +0200, Mark Kettenis wrote: > On ARMv8, the translation table walk is fully coherent so there is no > reason to explicitly flush the cache before invalidating the TLB. The > barrier that is included in out TLB flushing code should be enough to > guarantee that the TLB walking hardware sees the updated page table > contents, so the explicit barriers can go as well. Diff also > sanitizes the code immediately around the removed bits of code to drop > redundant curly braces, avoid C++ style comments and removes some > blank lines that aren't particular useful. > > Can somebody give this a spin on hardware with a Cortex-A57 and verify > that this doesn't make things more unstable? I didn't encounter any problems running a make build with this change. It also slightly improved the build time: 291m24.74s real 257m59.41s user16m05.09s system 286m32.07s real 255m44.31s user15m22.44s system
