Re: vlan tagging surgery
Henning Brauer lists-openbsdtech at bsws.de writes: And lot of (possible) encapsulation subsystems in the middle: vlan, vlan-in-vlan, ipsec, you name it. VLAN IS NOT AN ENCAPSULATION. Well, vlan(4) says: vlan, svlan - IEEE 802.1Q/1AD encapsulation/decapsulation pseudo-device Given a number of subsystems, delayed processing (promise pattern variation, actually) is way to go, imo, because stack will have homogeneous approach for entire packet assembly logic. you cannot delay this reasonably, it IS far down the road, basically right before sending the frame out. In terms of above pattern, right: vlan_output will only set a flag and call ether_output - this is what you already did with cksums. no, not even remotely. sigh. Functionally, no, - I understand your point. But I'm talking about *pattern* you used. Looking at what Martin is doing, imo, you guys trying to achieve a) concentrate all packet (re)assembly in one place to minimize memory operations (so you need to delay some things); b) put one lock in and one lock out (you also need to delay to be able to put one single block of code somewhere in the output). What I see, old (spaghetti) approach and new (delayed) approach are trying to coexist. Alexey, Since you don't supply diffs, you are a waste of skin.
Re: more axeing at openssl
This replaces RAND_{,pseudo_}bytes() calls with equivelant arc4random_buf(3)
calls for apps/ and ssl/ (crypto/ still has a bunch).
Actually last time this was discussed, the idea was to leave this as-is for
now. Then we can decide if the stronger of the two should remain a seperate
name. There's all sorts of long-term consequences from prematurely folding
this.
Re: [patch ping.c] replace malloc memset with calloc
You are now clearing only the first time.
malloc memset can be replaced with calloc in ping.c. Please see below
for patch details:
Index: ping.c
===
RCS file: /cvs/src/sbin/ping/ping.c,v
retrieving revision 1.100
diff -u -p -u -r1.100 ping.c
--- ping.c24 Mar 2014 11:11:49 -1.100
+++ ping.c22 Apr 2014 04:41:56 -
@@ -508,8 +508,8 @@ main(int argc, char *argv[])
catcher(0);/* start things going */
fdmasks = howmany(s+1, NFDBITS) * sizeof(fd_mask);
-if ((fdmaskp = (fd_set *)malloc(fdmasks)) == NULL)
-err(1, malloc);
+if ((fdmaskp = calloc(1, fdmasks)) == NULL)
+err(1, calloc);
for (;;) {
struct sockaddr_in from;
@@ -521,7 +521,6 @@ main(int argc, char *argv[])
pinger();
timeout.tv_sec = 0;
timeout.tv_usec = 1;
-memset(fdmaskp, 0, fdmasks);
FD_SET(s, fdmaskp);
if (select(s + 1, (fd_set *)fdmaskp, (fd_set *)NULL,
(fd_set *)NULL, timeout) 1)
Re: LibreSSL OPENSSL_malloc... removal
The removal of OPENSSL_malloc/OPENSSL_free ... etc will cause a LOT of pain Which is why they are not removed. There is non négligeable number of applications which are strongly depending on this functionality, they use it for example to allocate SSL data structures in memory shared between multiple forked instances... One example of such application is Kamailio (sip server). Would you mind to reconsider removal of these routines? They are not removed. Pay attention.
Re: pckbd volume keys (part 2): knob to pass keystrokes
this diff applies on top of the previous one; it adds the hw.kbdvolume sysctl(1) entry to select how pckbd ukbd volume keys are handled: hw.kbdvolume=0 pass keystrokes to upper layer as we do for regular keys, thus usable by X apps as hot-keys or whatever. hw.kbdvolume=1 change the ouputs.master control of the first audio device, keystrokes are consumed by the kernel and not visible by userland. This is the default, as this is the behavior of all other (acpi, macppc, ... ) volume keys. This approach is simplestic and wrong.
Re: patch: use a lookup table in BIO_get_port()
Don't bother with diffs to b_sock.c. Instead, if you have code
which uses it, talk to krw.
There is a monster diff coming which rewrites it all.
And by the way, all that code disapears and is replaced by 2 lines.
Not sure this is sensible as it encourages people to simply
update the table.
I was inclined to remove the code entirely but I am not sure
what broken systems might rely on this.
Only build tested.
Thoughts?
Index: b_sock.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/bio/b_sock.c,v
retrieving revision 1.33
diff -u -p -r1.33 b_sock.c
--- b_sock.c 26 Apr 2014 18:56:37 - 1.33
+++ b_sock.c 29 Apr 2014 13:55:39 -
@@ -140,6 +140,19 @@ BIO_get_port(const char *str, unsigned s
{
int i;
struct servent *s;
+ size_t len;
+ struct {
+ const char *name;
+ int port;
+ } servmap[] = {
+ { http, 80 },
+ { telnet, 23 },
+ { socks, 1080 },
+ { https, 443 },
+ { ssl,443 },
+ { ftp,21 },
+ { gopher, 70 }
+ };
if (str == NULL) {
BIOerr(BIO_F_BIO_GET_PORT, BIO_R_NO_PORT_DEFINED);
@@ -155,21 +168,14 @@ BIO_get_port(const char *str, unsigned s
*port_ptr = ntohs((unsigned short)s-s_port);
CRYPTO_w_unlock(CRYPTO_LOCK_GETSERVBYNAME);
if (s == NULL) {
- if (strcmp(str, http) == 0)
- *port_ptr = 80;
- else if (strcmp(str, telnet) == 0)
- *port_ptr = 23;
- else if (strcmp(str, socks) == 0)
- *port_ptr = 1080;
- else if (strcmp(str, https) == 0)
- *port_ptr = 443;
- else if (strcmp(str, ssl) == 0)
- *port_ptr = 443;
- else if (strcmp(str, ftp) == 0)
- *port_ptr = 21;
- else if (strcmp(str, gopher) == 0)
- *port_ptr = 70;
- else {
+ len = sizeof(servmap) / sizeof(servmap[0]);
+ for (i = 0; i len; i++) {
+ if (strcmp(str, servmap[i].name) == 0) {
+ *port_ptr = servmap[i].port;
+ break;
+ }
+ }
+ if (i == len) {
SYSerr(SYS_F_GETSERVBYNAME, errno);
ERR_asprintf_error_data(service='%s', str);
return (0);
Re: IPv6 by default
I know that what I proposed cannot go in at the moment. It's my end goal. The goal is ridiculous. If anything, it should be sorted by the best addresses first. Today the best addresses are IPv4. There is no dynamic method to determine best, but measurements all over the world show that IPv4 is better in every respect. Change that, then we can talk.
Re: IPv6 by default
Someone has to take the first/next step, and that's a very traditional role for OpenBSD. Apply these kinds of changes to your entire production network, and report back in 6 months if you are still running them.
Re: IPv6 by default
However, based on available evidence, IPv4 is not better than IPv6 in every respect for everyone. You've written a long mail and completely missed the point. This is not a conversation about your IPv6 connection. It is about what the sensible default should be for everyone.
Re: data modified on freelist, tmpfs-related?
On Wed, Apr 30, 2014 at 03:38:39PM +0200, Mark Kettenis wrote: Date: Wed, 30 Apr 2014 13:39:20 +0100 From: Stuart Henderson st...@openbsd.org Seen when running e2fsprogs regression tests with /tmp on tmpfs I'm not surprised; tmpfs contains some serious bugs. I recommend not using it until those are fixed. On the other hand, if we don't use it, we won't find bugs... ;-) That particular bug has been found before. Re-discoverering it is not getting it fixed. Like everything, tmpfs has to be fixed by those who care.
Re: Questions about LibreSSL
I have been following the recent LibreSSL developments quite active and would like to contribute. I have some questions: - The accelerated assembly code for the crypto, is that gonna stay? Of course. Why do you think anyone would try to break code which works? - Why not use uint32_t and uint64_t all over (incl the APIs) instead of custom XX_ULONG stuff? I believe Miod is working at improving this. It situation is far more complex than you could believe. My brain recoiled when I started to understand the classes of theoretical machines being supported. AFAIK uint32_t and uint64_t are guaranteed 4 and 8 bytes long. Sigh. You don't see to understand the OpenSSL tree. It contains support for machines that have already turned into gas at the bottom of garbage dumps. - Can we eliminate #ifdef OPENSSL_NO_AES and that for all the crypto (bf, des etc.)? What problem are you trying to solve? - The FULL_UNROLL macro in aes_locl.h is that gonna stay? Why not? What is broken with it? Is this on the critical path? Do you think that introduces scary risk for people? Please read the current commit logs to understand the focus of the task.
Re: malloc freelists
Sorry, badly phrased reply. I didn't mean to imply it was a bad idea, but you didn't explain at all why 4, and not 3 or 6, or 42 ? If it's good with 4, it ought to be better with more, right ? any data point or rationale for choosing 4 ? Why does Ted have to explain his heuristic? Should all pkg_add design changes have to undergo the same public scrutiny? Should do we go through the last 10 commits and create a fuss? Chill dude. 4 looks good to me. Shrug.
Re: not quite another erratum
The process which came to the conclusion below took about 15-20 hours of accumulated developer time over the weekend. I'm almost running out of fingers counting developers. I wish we had the resources so that we could dedicate people to this in a more serious way. At least if we could dedicate them for a while, until this codebase has become wittled down. But we don't. Yes, that is a hint. It could be like the KMS effort over the last two years. Lacking that, this situation below is going to repeat itself again. Actually, it will repeat itself tomorrow A little background. Before we issue errata, we have to decide whether we should. That's usually pretty simple, but sometimes a bug looks exploitable when it isn't, or is exploitable when it looks benign. Clearly issuing zero errata isn't a workable solution, so we could issue errata for everything, but that leads to patch fatigue. Instead, we pick and choose as best we are able. Sometimes that's hard. Our primary focus is not on developing exploits. We have limited time and many other things to work on, and there is no reward for us to continue investigating exploit potential beyond a certain point. Referring now to a specific commit by jsing, see the commit for details. The bug's existence was publicly disclosed 3 years ago; I'm not about to reveal anything particularly secret. http://marc.info/?l=openbsd-cvsm=139913610412127w=2 The first issue is being able to trigger a memcpy with a small negative (huge unsigned) length. In general, any memory corruption can lead to code execution, but the specifics are application dependent. It's only a problem if there's privilege escalation involved. PEM encoded certs aren't used in the TLS wire protocol, for example, so network services are not affected. The second issue is that the incorrect handling of base64 padding will also decode to different bytes than a correct implementation. In general, any time two parsers process the same input and generate two different outputs that can lead to a security bypass, but again, the specifics are app dependent. We looked at these issues for a while and couldn't see a means to exploit them that would justify issuing a patch, but we can't rule out that possibility either. We neither want to cry wolf nor hide the truth. Lacking a clear consensus that we should patch or not patch, what you're getting instead is this email. (I initially proposed a patch and an email saying the patch was unnecessary, but it seems less confusing to simply send the email.) This email doesn't offer a lot of guidance about what to do, for which I apologize. At least now you know what we know.
Re: [patch] libssl/src/ssl/ssl_rsa.c
Your diff does not solve a problem.
In case this is considered important enough...
Remove unused ret from SSL_use_PrivateKey().
- Michael
Index: ssl_rsa.c
===
RCS file: /cvs/src/lib/libssl/src/ssl/ssl_rsa.c,v
retrieving revision 1.11
diff -u -r1.11 ssl_rsa.c
--- ssl_rsa.c 17 Apr 2014 21:37:37 - 1.11
+++ ssl_rsa.c 9 May 2014 03:46:58 -
@@ -273,8 +273,6 @@
int
SSL_use_PrivateKey(SSL *ssl, EVP_PKEY *pkey)
{
- int ret;
-
if (pkey == NULL) {
SSLerr(SSL_F_SSL_USE_PRIVATEKEY, ERR_R_PASSED_NULL_PARAMETER);
return (0);
@@ -283,8 +281,7 @@
SSLerr(SSL_F_SSL_USE_PRIVATEKEY, ERR_R_MALLOC_FAILURE);
return (0);
}
- ret = ssl_set_pkey(ssl-cert, pkey);
- return (ret);
+ return (ssl_set_pkey(ssl-cert, pkey));
}
#ifndef OPENSSL_NO_STDIO
Re: NOINET6 by default
* Mark Kettenis mark.kette...@xs4all.nl [2014-05-15 00:15]: I don't think this is a good idea; didn't we establish the other day that ifconfig if eui64 already did what your +inet6 does? almost, it's ifconfig if inet6 eui64 - but that isn't all THAT intuitive. I like +inet6 as the opposite of -inet6. I am rather late to the conversation. We don't have + something. It is foo or -foo but not +foo. I know that inet6 is already used for the regular addresses, but +inet6 sounds like an inconsistent workaround for a workaround. I don't like it. I agree. To enable IPv6 link-local I would rather prefer two options to put either inet6 eui64 (or an alias like inet6 link-local) or an actual inet6 address in your hostname.if. The latter should automatically remove the flag and enable the link-local address - does it work this way? I also agree. I do not like the word 'link-local', because it implies L2. What we are removing here is wire-local access via L3. I'd prefer to avoid the word local if we can... There is also a third path. That is to change the behaviour of 'ifconfig if proto', or more specifically of 'ifconfig if inet6'. But this will assuredly break someone's scripts...
Re: libssl remove SSL_(set|get)_(time|timeout)
I'm not sure how much, and if this breaks anything in Ports. Then you need to go find out. According to github it isn't used much. Whoa. Think about that for a while. You want to disrupt the application authors ... now?
Re: libssl remove SSL_(set|get)_(time|timeout)
On Thu, May 29, 2014 at 21:00, Alexander Schrijver wrote: I'm not sure how much, and if this breaks anything in Ports. According to github it isn't used much. We're going to keep this for a while. We would like to keep as much API compatibility as possible, even when the API is mostly useless. The exceptions are generally for APIs which simply cannot be used in a secure manner. Of course, there were other exceptions, when we tried to delete what appeared to be obsolete functions, but then we discovered people still use them, which created a mess. These functions don't appear particularly harmful. I want to throw in a few words. A fair amount of application code is written in a style of #ifdef LINUX a whole whack of code #elif ANOTHERSYSTEM the same code, with with a small difference #... The abstractions taken by the developers are sometimes not as fine as they could be. The problem with removing APIs too quickly in libressl, is that while we might see the OpenBSD ports works fine, the other code blocks on other systems may use the API, and then fail. At a much later time, after libressl is tried on those systems. So for fairly uncommon, not so scary, but stupid APIs, we would prefer to defer the deletion till a bit later.
Re: 9p
However, as we've seen with lots of things that touch vfs it's pretty easy to get to 80 or 90 percent functionality and then the last 10% is a royal red pain in the butt, with possibly awful crashing bugs. The word possibly makes that sentence too optimistic.
Re: 9p
Yes, that's true. you *WILL* have awful crashing or hanging bugs to chase ;) Welcome to the midlayer. Wine bottles are optional but highly recommended. And dual purpose. 1) drink it with pleasure in the company of a VFS hacker 2) when the midlayer breaks, beat the VFS hacker over the head
Re: [PATCH 4/7] use BIO_write instead of an unchecked write()
Your change is wrong.
There have been lots of discussion about trying to use intrinsics as
much as possible. Even though this is the openssl command, I think
the consideration is also valid here.
You've just run into the reason for using intrinsics as much as
possible. BIO_write is different from write. See how insane this is?
Anyways, the compiler is telling you to check the return value.
Why don't you check it, and put in some effort determining what action
to take in that case?
The result will be better.
write() warns if its return value is unchecked. Replace with a BIO_write
like all of the surrounding code uses anyway.
---
src/apps/s_server.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/apps/s_server.c b/src/apps/s_server.c
index 51f6b47..fb28489 100644
--- a/src/apps/s_server.c
+++ b/src/apps/s_server.c
@@ -1767,7 +1767,7 @@ sv_body(char *hostname, int s, unsigned char *context)
i = SSL_read(con, (char *) buf, bufsize);
switch (SSL_get_error(con, i)) {
case SSL_ERROR_NONE:
- write(fileno(stdout), buf,
+ BIO_write(bio_s_out, buf,
(unsigned int) i);
if (SSL_pending(con))
goto again;
--
1.9.3
Re: [PATCH 1/3] Check output of write() to stdout
This diff is very dissapointing.
Check for errors on write. Since SIGPIPE is ignored, play nicely with
pipelines by aborting on EPIPE.
---
src/apps/s_server.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/apps/s_server.c b/src/apps/s_server.c
index 77384ec..836d46b 100644
--- a/src/apps/s_server.c
+++ b/src/apps/s_server.c
@@ -1760,8 +1760,11 @@ sv_body(char *hostname, int s, unsigned char *context)
i = SSL_read(con, (char *) buf, bufsize);
switch (SSL_get_error(con, i)) {
case SSL_ERROR_NONE:
- write(fileno(stdout), buf,
- (unsigned int) i);
+ if (write(fileno(stdout), buf, i) ==
-1) {
+ if (errno == EPIPE) {
+ abort();
+ }
+ }
if (SSL_pending(con))
goto again;
break;
--
1.9.3
Re: [PATCH 2/7] fix type string conversion warning
On Mon, Jun 02, 2014 at 12:33:14PM -0400, Ted Unangst wrote: What compiler warns about this? It's perfectly fine to pass a nonconst string to a function that takes a const string. char * vs unsigned char *? So this is a great way to lose focus. The agenda is a step-by-step refactoring of the codebase, without causing accidental harm to the API. Each simplification step should make the code simpler, more accessibile for analysis by skilled peopke, resulting in further improvement; security will improve step-by-step hopefully without any other downsides. You can be part of that agenda. Or, we can go bikeshed about compiler warnings which are clearly false positives. Under the assumption that these conversations have no time-wasting impact on the people doing real work to make things better. You can figure out what I'm not saying on this line.
Re: 9p
Matthew, you obviously did not spot the evil 9p/util.h yet. This file ought to be named ozymandias.h. Also, I am vetoing the addition of -fms-extensions to the kernel build options. Whatever files require this option to build needs to be fixed to be proper, unambiguous, C99, instead. I feel I need to go further with commentary. This will strike some as mean. I believe I found one line in the diff which didn't violate community standards, and it was a blank line. The rest... sorry, but it is off our map. This entire diff feels like it is being thrown at us to distract some developer from more important work. Congratulations, it has worked! For a bit... and I hope at this point it ends.
Re: ld.so take 2
+ if (optr != NULL) {
+ _dl_write(STDERR_FILENO, msg1, sizeof(msg1) - 1);
+ _dl_exit(7);
+ }
I think this is a trap. A true realloc is not much to add. It can
be the simple always realloc method, since actually that is better
for security right off the bat
Re: ld.so take 2
The new malloc has been comitted, so now take the next step. This changes _dl_malloc to a regular non-zeroing _dl_malloc and uses _dl_calloc and _dl_reallocarray. This needs carefull review. Yes very careful. Otto is basing this part off ugly ld.so refactoring tree I shared with him. It took me many days to get it working the first time.. Please check carefully. In summary: current ld.so malloc() has an implicit bzero. This is moving us to no implicit bzero, the callee has to that work. Just like the intrinsic behaviours of the libc variants. At the same time, the more sophisticated calloc() and reallocarray() versions are added...
Re: syncing libc and libkern
However, seeing as things are maintained separately (for good reasons), perhaps copy-to-libkern itself should just be removed since it's basically pointless at this point and hasn't been used for about a decade. I think that is the right direction. Then, do a seperate cleanup.
Re: new OpenSSL flaws
Em 05-06-2014 15:42, dera...@cvs.openbsd.org escreveu: We are sorry that the errata for these libssl security issues are not up yet. The majority of these issues are in our ssl library as well. Most other operating system vendors have patches available, but that is because they were (obviously) given a heads up to prepare them over the last few days. OpenBSD / LibreSSL did not receive any heads-up from OpenSSL. So hold on, we'll try to have errata out in a few hours. Theo, I'm just curious, but, this happened in the past? Sure, it has happened in the past. But probably not to this degree. Some sort of timeline has been published. Read between the lines. http://seclists.org/oss-sec/2014/q2/466
Re: new OpenSSL flaws
There are two main open-source processes for dealing with discovery of security issues and disclosure of that information to the greater community. - One common process is that generally followed by OpenBSD. In this proocess a bug is found, and a fix is commited as soon as the improvement is known to good. Then if an asssement has been done, and it is determined to be important, disclosure occurs, of course after the commit is already public. Everyone including the vendors had the opportunity to get the information in a fair and equal way. - The other main process used by some open source groups, is to quarantine important repairs. A fix is firsst disclosed all affected parties, or at least the right concerned subset. This creates a delay before information availability, but the coordination is intended to provide a benefit. Everyone generally gets the information in a fair and equal way. Both processses have their place. Each software group has their own limitations and needs which will drive their selection. Is clear that the second process -- intending to also take an ethical path for disclosure -- should not specifically exclude a part of the community. Unfortunately I find myself believing reports that the OpenSSL people intentionally asked others for quarantine, and went out of their way to ensure this information would not come to OpenBSD and LibreSSL. There, I've said it.
Re: new OpenSSL flaws
Is clear that the second process -- intending to also take an ethical path for disclosure -- should not specifically exclude a part of the community. They specifically exclude parts of the community that specifically say they don't want to be INCLUDED. See: http://seclists.org/oss-sec/2014/q2/233 Dear Anonymous, That discussion is unrelated. I made a personal statement that I did not wish to participate in another private mailing list, stating my reasons as clearly as I could. My personal participation in such a mailing list is very distinct from OpenSSL's social responsibility to inform - the 10+ developers working on LibreSSL (I am only a minor part of that sub-group). - the security-concerned sub-group of OpenBSD (I play a big part in that, but not in regards to the SSL subset, so at most I would have handed this to the LibreSSL subgroup) Dr. Henson of OpenSSL knew who to contact. The other members of the private mailing list were witness to the disclosure gap. The choice was made there. I cannot be held responsible for this lack of notification.
Re: new OpenSSL flaws
That's exactly my though. Specially, because FreeBSD and NetBSD were warned, but not OpenBSD. If this was only a rant or any childish behavior from them, it's something stupid and, of course, not the right thing to do. But hey, we're all human. My real concern is if this something else, a hidden agenda, in that this stupid disclosure was indeed, carefully planed. One can never have too many conspiracy theories. Specially after what has been happening the last year. Thanks for the clarification. Mark Cox claims that the reason OpenBSD was not told is because OpenBSD is not on the distros mailing list and if we were then they'd be able to work with other distros on issues in advance. It's at http://oss-security.openwall.org/wiki/mailing-lists/distros . Not saying I believe or disbelieve him, but it can't hurt to join even if it is only until 5.6 comes out. That is an interesting claim. It sounds like we should test it, rather than take it as fact. Let's ask the right people. Kurt and Solar -- You are the primary contacts for the oss-security email list. Are you are aware of any operating system, product suppliers, or service providers who were notified early by OpenSSL... but are not found on the private mailing list? I think it would be poor style to ask for specific names, but a vague statement confirming or denying things would be nice. There are claims that attendance on your private email list is required sufficient for early disclosure from OpenSSL. Thanks in advance for any clarity you can supply to this question.
Re: new OpenSSL flaws
Not saying I believe or disbelieve him, but it can't hurt to join even if it is only until 5.6 comes out. Another way to phrase this is The OpenBSD user community should accept they have suffered because Theo declined an invitation to a private email list, entirely unrelated to the vendor who was in control of deciding where the notification would go. Right. That's a good one. I will not join that list. It would not have helped. I do not do work in SSL; there's 10 other people on our group who do that. Shall I send a request that all 10 of our SSL sub-group join that list, because there's a lot of SSL-related shit coming down the pipe soon? Heck, why don't they just let anyone join...
Re: new OpenSSL flaws
I suggest you talk to Mark Cox who actually handled this stuff. I'm not sure why you are asking two people (myself and Solar) who are NOT part of the OpenSSL team about whom the OpenSSL team notified. Kurt, if Mark Cox is the person who handled this stuff, fine. Who cares? I am hearing claims all over the place regarding a list RUN BY YOU. FACT: Kurt Seifried and Solar Designer are the two primary operators of the openwall security list, the declared access point for security issues affecting Linux operating systems. There are claims being lodged that disclosure of these OpenSSL problems happened on that list. There are claims that we did not get this disclosure because OpenBSD is not on that list. Particularily me, Bob, and Todd Miller. Kurd, is that true? Is that how you see it? Were disclosures handled there, or via another platform or method? ANSWER THE QUESTION. If you won't answer this question, noone should ever trust you again for anything. I'm done playing games with you Theo. You were invited to join distros publicly and flamed me. I privately emailed Bob Beck inviting him to join, and he flamed me (but then apologized), You both said no. I can't do anything more. I wish you the best of luck in your future endeavors. I am not playing any games. Let's look at the facts. Kurd Seifried is an official Red Hat security officer (of sorts, but probably not tomorrow) Kurt, is Mark Cox your supervisor? A claim is being made that disclosure to OpenBSD needs to be on a Russian email list run by you (Kurt Seifried) and Solar Designer (not going to include his real name) for access to early disclosure of important security information. SO ANSWER THE FUCKING QUESTION, KURT. Or else, if you are a wimp, have your Mark Cox answer the fucking question. Red Hat and OpenSSL -- answer the fucking question. Why was the OpenBSD user community excluded from this information? Why are there public accusation -- from Red Hat officers -- that OpenBSD developers only get advance access to information if they join a Russian located email list? ps. Who is Mark Cox? I've never heard of him.
[no subject]
Fcc: +outbox Subject: Re: that private mailing list (fwd) Solar Designer: Re: that private mailing list I haven't even read this. I don't care. if this is the situation with open source disclosure, all of you users are fucked. --- Forwarded Message Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by cvs.openbsd.org (8.14.8/8.12.1) with SMTP id s564LjFg027340 for dera...@cvs.openbsd.org; Thu, 5 Jun 2014 22:21:46 -0600 (MDT) Received: (qmail 19629 invoked from network); 6 Jun 2014 04:21:39 - Received: from localhost (HELO pvt.openwall.com) (127.0.0.1) by localhost with SMTP; 6 Jun 2014 04:21:39 - Received: by pvt.openwall.com (Postfix, from userid 503) id 82DA048BCE; Fri, 6 Jun 2014 08:21:05 +0400 (MSK) Date: Fri, 6 Jun 2014 08:21:05 +0400 From: Solar Designer so...@openwall.com To: Theo de Raadt dera...@cvs.openbsd.org Subject: Re: that private mailing list Message-ID: 20140606042105.gb26...@openwall.com References: 201406052157.s55lvh7j020...@cvs.openbsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 201406052157.s55lvh7j020...@cvs.openbsd.org User-Agent: Mutt/1.4.2.3i Hi Theo, I'll reply only in private first, because I am referring to the past discussion we had in private and that you didn't want to be made public. Also, please note that I wrote the below with no hard feelings, and I don't mean to offend you. I am just being sincere and direct. I think that is your preferred way to communicate, so I've adopted it. :-) On Thu, Jun 05, 2014 at 03:57:43PM -0600, Theo de Raadt wrote: I only know parts. It sound like some people who claim they stand up for what is right really don't stand up for what is right. I can't comment about OpenSSL folks, but my own impression certainly was that you didn't want your project to be provided advance notification - not only via distros list, but at all. Now you're saying you actually wanted folks on your team to be notified, just not you personally. Hmm? As you had mentioned to me in the private discussion when stu@ wanted to get OpenBSD onto distros, you didn't want folks on your team to accept any kind of embargo. I wish we had that discussion in public, as I had suggested at the time. You objected to that. (And I understand that with that discussion in public you might not have been willing to blame some others in it, which would possibly hamper my understanding of your position. So your objection did make some sense.) Now you appear to be misinforming folks on your own team (I hope not intentionally) that those evil people on distros list and OpenSSL maintainers deliberately didn't want to notify you. You might be right about OpenSSL maintainers (although I think you are not) - I just don't know, and can't speak for them - but at least for me (as someone who was notified via distros list) it appeared that you actually didn't want your team to be notified in a manner that would impose any restrictions on when you can commit a fix. So, believe it or not, it didn't even occur to me to put your project in a position where your folks would be asked to accept an embargo, which you didn't want. Would you like me to suggest (to whoever reports an issue) that someone on your team (who?) be notified next time an OpenSSL issue is brought up on distros? (It doesn't have to be one person on your team - it can be several. This is to address Bob's comment on your lists.) What about issues in other projects (not OpenSSL)? Which other projects would you also like notifications about? It appears that you've made a (political) decision for your projects not to join distros (or possibly any such channels in general), but are now asking for people/projects to be notifying your folks anyway when appropriate (whatever that means), and this is difficult for everyone. How do you suggest we make things better (in whatever sense you like) going forward? /sd --- End of Forwarded Message
Re: mfi(4) vs WT and WB
Which has an OK battery but still reports itself as being in WT mode: So what's the status of this WT/WB flag? Can't it be trusted for PERC 6/i and maybe other adapters? If so, a man page blurp would be needed imo. Difficult experiences have taught me to mistrust all the sensors coming from certain generations of controllers. It feels like they have a mode where they determine themselves obsolete and start punishing the ower.
Re: increase netcat's buffer...
A better patch is probably the following which also increases the size of the buffer to at least 64k: Agreed. One thing to be aware of. That function is syncronous. It will read as much as it can get, then it will do an atomic write operation to flush the buffer out the other way. If you have substantially different speeds, this can be a substantial 'buffer bloat'. Since it is handling a session in both directions... expect to see some substantial jaggies.
Re: [PATCH] Use mkstemp instead of mktemp.
And you tested to make sure that it works after your change?
Fascinating.
mktemp was removed from POSIX 2008 for security reasons.
---
usr.bin/nc/netcat.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/usr.bin/nc/netcat.c b/usr.bin/nc/netcat.c
index a034bba..d9e4ab4 100644
--- a/usr.bin/nc/netcat.c
+++ b/usr.bin/nc/netcat.c
@@ -283,8 +283,8 @@ main(int argc, char *argv[])
} else {
strlcpy(unix_dg_tmp_socket_buf, /tmp/nc.XX,
UNIX_DG_TMP_SOCKET_SIZE);
- if (mktemp(unix_dg_tmp_socket_buf) == NULL)
- err(1, mktemp);
+ if (mkstemp(unix_dg_tmp_socket_buf) == NULL)
+ err(1, mkstemp);
unix_dg_tmp_socket = unix_dg_tmp_socket_buf;
}
}
--
2.0.0.526.g5318336
Re: We can dump(8) more than 2TB
Date: Thu, 12 Jun 2014 15:14:29 -0400 From: Ted Unangst t...@tedunangst.com On Thu, Jun 12, 2014 at 21:07, Christian Weisgerber wrote: After writing 2TB (INT_MAX * TP_BSIZE), dump(8) stops reporting progress because the blockswritten variable has wrapped around to negative. It needs to be a larger type like the tapesize variable; see optr.c:timeest(). This only affects the terminal chatter. The actual dump functionality is fine. int notify; /* notify operator flag */ -int blockswritten; /* number of blocks written on current tape */ +off_tblockswritten; /* number of blocks written on current tape */ int tapeno; /* current tape number */ time_ttstart_writing; /* when started writing the first tape block */ long xferrate; /* averaged transfer rate of all volumes */ I'm not sure off_t is the right semantic type. Perhaps just use int64_t? int64_t is what we use in struct stat. That said, there is existing off_t abuse in dump. I seperately pointed out to naddy that blocksperfile is also mishandled; it will also overflow. It is printed with a %ld somewhere, so fix that too.
Re: diff: add tuning variables to config(8)
Followings are our kernel variables' default: - sb_max: 256K - tcbhash_size: 128 - udbhash_size: 128 These variables are sometime too small for busy server or gateway. I'd like to modify config(8) to customize these variables without recompiling the kernel. If we go this route, I would rather have a generic command (such as set kernel variable name value) to change kernel variables. The list of said variables would still be restricted to what a given config(8) knows, to prevent people from tinkering with things they are not supposed to touch. I quite dislike the direction this is going. It seems like you have found 3 variables which should auto-tune. So why not write kernel code to auto-tune them?
Re: increase netcat's buffer...
It should not use kevent. That makes the code non-portable. Use poll().
Re: compare memcmp with 0
Always explicitly compare memcmp with 0. I find this adds clarity. If you don't care which way a different comparison points, then why not use bcmp? Because knowledge of the difference in is scarce. Someone will screw it up. It could be argued that the bcmp manual page does a poor job documenting this. It should use the mandoc blink tag.
Re: compare memcmp with 0
If we use timingsafe_bcmp widely (safe as that may be), it's very hard to convey the idea that there are circumstances when it is not safe. Using timingsafe_memcmp raises its awareness and will make it other developers' default choice. Exactly. It is easier to develop a pattern/meme when the choice is simple to remember. If the decision tree is too complex, people simply walk away. The performance cost is totally irrelevant.
boringssl and such
Few things to note... I suspect everyone working on LibReSSL is happy to hear the news about BoringSSL. Choice is good!! Their priority is on safety, not on ABI compatibility. Just like us. Over time, I suspect google's version will also become 'reduced API', since they require less legacy application support. That may give LibReSSL the opportunity to head in the same direction, if the applications are willing... Secondly, a lot of misinformation is being spread about the effort required to get LibReSSL-portable out the door. We've stripped the code so that it is POSIX-only. Therefore Linux compat is really not hard. We basically just need the following parts to be finished: - A clean build framework - and the finetunings of portable versions of our safetybelts: arc4randomstrlcpy strlcat explicit_bzero reallocarray timingsafe_bcmp timingsafe_memcmp So please stop believing rumours that we've made it hard to port! The entire world went to POSIX, and that's all this code needs to support. It is a small step. I don't think it will take much longer. patience...
Re: porting arc4random (was Re: boringssl and such)
having just this evening updated Android to the current arc4random
(https://android-review.googlesource.com/#/c/99052/), i was confused
by the single use of explicit_bzero amongst the many calls to memset
in the same file. as for portability, Linux requires MAP_PRIVATE
anywhere you use MAP_ANON, and needs something along the following
lines instead of the BSD sysctl:
int fd = open(/dev/urandom, O_RDONLY);
if (fd == -1) {
__libc_fatal(failed to open \/dev/urandom\: %s, strerror(errno));
}
ssize_t bytes_read = TEMP_FAILURE_RETRY(read(fd, rnd, sizeof(rnd)));
if (bytes_read != sizeof(rnd)) {
__libc_fatal(couldn't read %zu bytes from \/dev/urandom\: %s,
sizeof(rnd), strerror(errno));
}
close(fd);
The base arc4random() now relies on MAP_INHERIT_ZERO support in the
minherit() system call, this it can avoid the getpid() check.
-portable arc4random will not follow this lineage. -portable will
require a tweaked arc4random, based on 1.33
Re: NOINET6 by default
I'm volunteering for this job. I know that other people have already expressed interest in such a task. Can we please postpone ifp-if_xflags |= IFXF_NOINET6; until the situation is more clear? I think 5.6 is a safe bet. No. Apparently you are the only one who keeps postponing action, month after month, so NO.
Re: infnan.3
It's obvious that whole page needs a content update by a VAX expert. that is correct. All the rest of the discussion is moot. Only miod and martynas can swing this the right way. I disagree with Ted about making this a seperate page, since that would remove a vital component of floating point knowledge from programmers, that being: not all floating point is the same, not all of it is ieee, and not even ieee implementaiton is consistant. Some visibility must remain to show that there is sausage being made here.
Re: POSIX-compliant page fault error codes
Matthew -- fine, you collected information. Thank you. It is quite clear that POSIX set in stone an accident, a significant error in my opinion. Anyone with enough expertise can recognize this is an accident in the SVR4 codebase, which ended up being ratified (in quotes, because the more mistakes you make, the less value there is). This specific refinement may help a few pieces of code which require specific detail in siginfo, but it introduces a lot more accidental risk in those which only use the signal number/handler. It is complicated enough that it requires experts to review how (typically poorly) programs (written by non-experts) use signals to deal with this added kernel behaviour. As in, it is bad enough that I am scared even for the way that SIGBUS and SIGSEGV handlers in crap programs in base handle it. The issue of unsafe terminal signal handlers returns IN FORCE, and we need to cope with those. Nothing ever changes, noone ever learns, noone cares. Where we go from continues to be a big question mark. Compatible? one issue.. not compatible? another issue.. Thanks POSIX, whoever you are. What favors did you do us recently?
Re: slightly stricter check for genentropy_urandom
Here is a minor diff to do a little more strict checking on the device id for urandom. It would be a shame if someone replaced a genuine urandom with a /dev/null or some other predictable device. if a file is not special st_rdev will be 0 so S_ISCHR isn't needed anymore. So you are trying to protect against your machine being totally damaged already. It makes no sense at all. Those major and minor numbers do not make sense at all.
Re: slightly stricter check for genentropy_urandom
On 06/25/14 21:15, Theo de Raadt wrote: Here is a minor diff to do a little more strict checking on the device id for urandom. It would be a shame if someone replaced a genuine urandom with a /dev/null or some other predictable device. if a file is not special st_rdev will be 0 so S_ISCHR isn't needed anymore. So you are trying to protect against your machine being totally damaged already. It makes no sense at all. Those major and minor numbers do not make sense at all. Those numbers are what I found in urandom(4) and confirmed on Debian and CentOS. If you can find symbolic names in the headers I would love to add them instead of the magic numbers. And I'm trying to protect against the fact that if the machine has been damaged it will not use this API to generate anything that might bite us later on while the sys-admin could still be unaware of the problem. That is totally ridiculous. If this device node gets screwed up, then 500 other pieces of code without the check are going to fail. It might not be 100% foolproof, but it catches more and has about the same performance as S_ISCHR. Besides, if you have the stance on you should trust /dev/urandom, because else your system is already totally damaged, then why put a S_ISCHR there in the first place? For only one reason. If we didn't clone this chunk from all the other libraries which contain the same pattern, people would freak out. By the way, I think the file speaks clearly on the matter of our stance regarding /dev/urandom -- it is a hopelessly broken subsystem that cannot gaurantee access to random data in *all programming contexts*. (Such as file descriptor exhaustion).
Re: slightly stricter check for genentropy_urandom
Hello tech@, Here is a minor diff to do a little more strict checking on the device id for urandom. It would be a shame if someone replaced a genuine urandom with a /dev/null or some other predictable device. that's what the ioctl is for Actually, the ioctl does not do actually gaurantee that. Some other type of device driver could respond to #define RNDGETENTCNT_IOR( 'R', 0x00, int ) Somewhat like in the BSD's, ioctl's are encoded in a fashion that makes their numbers not strictly exclusive to a specific driver. While there is some attempt to keep these unique, there is no gaurantee in the drivers. I've not checked specifically, why would I.. it is the Linux kernel. Here is a writeup which seems to explain the situation. It's old, but probably still correct. http://www.mjmwired.net/kernel/Documentation/ioctl-number.txt
Re: Unnecessary mmap flags?
1. MAP_COPY is redefined as an alias for MAP_PRIVATE, and the other useless MAP_* flags are redefined to 0. They're also hidden from the kernel to make sure no kernel code accidentally depends on them still. 2. Adds COMPAT_O55_MAP_COPY so we can stay binary compatible with any OpenBSD 5.5 programs that still use MAP_COPY (probably none, but it's trivial to do), and COMPAT_O55_MAP_NOOPMASK just to keep track of which bits were previously reserved for do-nothing flags. Yes, then we can remove the kernel support soon. We need to remember to do that.. sometimes such things live far longer than the ABI requires. I suspect the new name might hurt kdump support (grep for mmapflagsname).
Re: Unnecessary mmap flags?
MAP_HASSEMAPHORE is used in rthread_sem.c, but it doesn't do anything, so I suspect it's just cargo culting based on man page misinformation? Are there architectures that actually have restrictions on semaphore memory? There architectures where atomic instructions only work on pages with certain caching attributes. Those attributes tend to be the default attributes though, so there is not much value in retaining this flag. Whether such architectures exist and want to do atomic handling is one thing. The real question is if any applications set the flag. Looks like no.
Re: POSIX-compliant page fault error codes
To prevent this from happening, the X server will install a signal handler for SIGBUS, check if a shared memory object is being accessed and patch things up (by mmap'ing anonymous memory on top of the mapping). This code can be extended of course by handling SIGSEGV as well. But this means more work in xenocara and ports, and we might miss some places where this needs to be done. I actually don't believe this theory about a SIGBUS (or even SIGSEGV) handler fixing things up. Over the last two decades, I've done more than a little auditing of signal handlers. The only general principle I can report back about them is that in general is that safe ones are exceedingly rare. Fixups are a myth. If it does happen, SIGBUS and SIGSEGV can be handled the same unsafe way...
Re: Rename MAP_ANON to MAP_ANONYMOUS
I don't think MAP_ANONYMOUS is being proposed for standardization because it's perceived to be of older origin than MAP_ANON or anything. I'm pretty sure the focus is instead because it's perceived to have greater 'market share' among present day systems and applications. Oh come on, the pussy footing is ridiculous. Let's call it what it is. The group is run a handful of Linux proxies. They do not care if incompatibilities are introduced, as long as they are not introduced for Linux.
Re: more deadbeef
how would you like your deadbeef? well done? since we support variable poison values, we should invert the patterns sometimes to find bugs where the deadbeef values hide the bugs. (we can of course do even more with extra tricksy bit patterns, but start with this.) I have been worried about this for quite a while. Especially for flag bits long explanation deleted.
Re: lynx: disable old protocols
Pretty standard thing in several companies I do work for is to have an intranet page with http://, ssh://, telnet:// and finger:// (amazingly) links to various devices on the network. Having to read the source and escape to a shell would be somewhat worse than what I get on a base install today. IIRC, finger was how we got a quick status overview from... some piece of ATM switching gear? And yes, I actually do spend a noticeable amount of time at the text console, with no ports installed, when inside a foreign network. -Adam This banter is annoying. Please go read the code in question, carefully. You only need to spend 30 minutes. It will change your mind.
Re: lynx: disable old protocols
I don't see a good reason to get rid of this. What is the rationale? Daniel appears to have made a mistake asking for approval on the wrong list. He's new here, take it easy on him.
Re: PATCH: add more malloc.conf details to malloc.3
I am a bit concerned. The description is trying too hard to be overly precise, and may be cumbersome for the typical reader of this page. Index: lib/libc/stdlib/malloc.3 === RCS file: /cvs/src/lib/libc/stdlib/malloc.3,v retrieving revision 1.78 diff -u -p -d -r1.78 malloc.3 --- lib/libc/stdlib/malloc.3 1 May 2014 18:41:59 - 1.78 +++ lib/libc/stdlib/malloc.3 11 Jul 2014 07:19:27 - @@ -220,10 +220,23 @@ Malloc will first look for a symbolic li .Pa /etc/malloc.conf and next check the environment for a variable called .Ev MALLOC_OPTIONS +(if not +.Xr issetugid 2 ) and finally for the global variable .Va malloc_options and scan them for flags in that order. Flags are single letters, uppercase means on, lowercase means off. +.Pp +The default flags are +.Cm A +and +.Cm P , +small chunks are always junked, and the first +part of the pages is junked after free. +The default junk behavior does not correspond to +.Cm j +or +.Cm J . .Bl -tag -width indent .It Cm A .Dq Abort . @@ -271,6 +284,7 @@ Currently junk is bytes of 0xd0 when all .Dq Duh . \:-) Freed chunks are filled with 0xdf. +This performs more junking than by default. .It Cm j .Dq Don't Junk . By default, small chunks are always junked, and the first part of pages @@ -297,6 +311,11 @@ This can substantially aid in compacting .\Consult the source for this one. .It Cm S Enable all options suitable for security auditing. +This currently enables flags +.Cm U , +.Cm J , +.Cm G +and sets the free cache page size to 0. .It Cm U .Dq Free unmap . Enable use after free protection for larger allocations.
Re: lynx: disable old protocols
I find lynx really handy to have in base, e.g. installing on a new machine, users can just go to openbsd.org and cut and paste a pkg_path prior to installing anything, and read the faq. that is why it is in base. but someone on the list wants to visit the openbsd gopher page to get that information. crazy people -- you are bat shit crazy.
Re: lynx: disable old protocols
If lynx was removed from base, and only available in ports... how many of you would even know of it's existance and use it?
Re: [PATCH] rdomain support on rc.d
Penned by Mike Belopuhov on 20140711 6:49.19, we have:
| On 11 July 2014 10:29, Antoine Jacoutot ajacou...@bsdfrog.org wrote:
| On Thu, Jul 10, 2014 at 06:51:01PM +0200, LoÄc BLOT wrote:
| Hello all,
| I use rdomains to split routing domains per company and also separate
| administration interfaces from routing interfaces on my routers (sshd,
| bacula, postfix and puppetd running on a dedicated rdomain)
|
| Actually there is a problem with rdomains, we need to modify /etc/rc.d
| scripts to add rdomain execution environment to the specified service.
| If rc.subr have support to rdomains, we can let the rc.d scripts clean.
|
| To resolve those rdomain issues, I created a patch and I added a new
| variable we could use on rc.conf(.local), ${_name}_rdomain. (This
| variable needs a signed integer and use an existing rdomain, this is
| checked by rc.subr.
|
| I want to contribute to OpenBSD and I give you this patch. If you have
| any suggestions to improve it, tell me.
|
| I don't use rdomain so someone knowledgeable should comment here.
| But it does look like a nice idea.
|
|
| having something like this would be really cool. in case you'll be
| tweaking the code, make sure that the route -T exec printf check
| is preserved. i would use true in this test however.
|
| as far as i can tell the daemon_rdomain bit that goes into the rc
| script is fine, however i'm not quite sure how can i start two
| daemons in different rdomains via rc.conf.local. looks like this
| diff doesn't handle this and allows only one instance in the
| ${_name}_rdomain rdomain. but sometimes you want multiple, say
| sshd in rdomain 0 and 1. daemon_rdomain flag allows me to go and
| create another rc.d/sshd-rdomain-1 script and stuff daemon_rdomain=1
| in there. but then i'd have to add it to the pkg_scripts... this
| is a minor issue that i see. perhaps ${_name}_rdomain should list
| multiple values, like sshd_rdomain=0,1,2,3.
multiple rdomain instances might even have different daemon_flags.
I think in addition to sshd_rdomain=0,1,2,3 the patch might handle
ssh_rdomain_0_flags=-C /etc/ssh/sshd_0_config. I'm guessing it
makes sense to add to sshd_flags= rather than over-write it, but
that's splitting hairs.
I've been wondering about how to implement what you've done, and
have ended up with 'route -T 3 exec /etc/rc.d/... -f' in /etc/rc.local.
I like this direction.
For crazy stuff, use /etc/rc.local
Re: CVS: cvs.openbsd.org: src
I'm worried that bogus codepaths will be taken in software that expects a certain openssl version - things failing to build we can cope with in ports easily enough, I'm more concerned about software that does build but behaves incorrectly at runtime. If the software is that fragile, then I am happy Bob, Joel, Miod, and Ted are simplifying the interface.
Re: lynx: disable old protocols
If there's a security hole related to gopher or bibp, let's fix it, let's not up and drop support for those protocols because of it. People do use these protocols even in 2014. let's is a contraction for let us. Basically the community must audit lynx, if they want it to remain in base. Those of us who have glanced judged it to be of poor quality. If it's code bloat, I'd like to know just how much code we're talking about. This is open source. You know you can find the source yourself and read it? Or .. perhaps you can't, and just wish to preach to us?
Re: CVS: cvs.openbsd.org: src
I am however curious about the rational behind this change. Does it solve any particular problem/risk? I seldomly use this style in my own scripts when I need to be able to dynamically determine variables at runtime. So it might be wise to know what hidden daemons I might be facing. The rc configuration file is becoming a well-managed clean file so that a mix of tools and admins can manage it. Not quite at the level of master.passwd, which is strictly controlled. Still admin editable, but well formed so that the future automatic tools won't screw up scripting in the file.
Re: lynx: disable old protocols
With your attitude, I beg you to please go run some other operating system.
Re: lynx: disable old protocols
Why haven't you left? Please leave. On Sat, 2014-07-12 at 23:58 -0700, William Orr wrote: wrt. auditing it, should we send patches here? Or upstream? I'd send them both places, if they apply cleanly to both sets of code. Otherwise, send them here. I'd love to be proven wrong about the maintainers not really giving a shit about the users, and accepting packages which make gopher browsing more secure or improve the code quality would help. BTW, I forgot to ask, where are the exploits for this poor quality code? i.e. if I'm browsing a gopher site with the current Lynx as root, what exactly do I have to stumble upon to get owned? Or is it just a this is ugly in a few places kind of vague feeling by some devs? I have a feeling there aren't any (exploits), but I thought I'd ask anyway. -- Shawn K. Quinn skqu...@rushpost.com
Re: lynx: disable old protocols
Why haven't you left yet Shawn?
Re: lynx: disable old protocols
You demand us to do work? Please leave immediately. On Sun, 2014-07-13 at 02:01 -0600, Theo de Raadt wrote: Why haven't you left yet Shawn? Because for the moment, I still am an OpenBSD user. And you haven't answered my question why there's been no exploit of this poor quality code (in the entire history of Lynx going back to 1992, no less). It's so easy to look at code and say it's shitty. It's another to prove it. -- Shawn K. Quinn skqu...@rushpost.com
Re: mallocarray() in sys/dev, first pass
Index: ic/malo.c - ring-data = malloc(count * sizeof (struct malo_rx_data), M_DEVBUF, - M_NOWAIT); + ring-data = mallocarray(count, sizeof (struct malo_rx_data), + M_DEVBUF, M_NOWAIT); Might as well s/sizeof (/sizeof(/ while you're here. And fix the interrupt handler while I am there, too? You missed the point of doing only one step.
Re: use mallocarray in kern
And some others from exec that follow a slightly different pattern. This is the pattern I have been following as well. As for the final diff, I've been giving up on the known constant scenario. It seems expensive. Index: exec_script.c === RCS file: /cvs/src/sys/kern/exec_script.c,v retrieving revision 1.30 diff -u -p -r1.30 exec_script.c --- exec_script.c 12 Jul 2014 18:43:32 - 1.30 +++ exec_script.c 13 Jul 2014 23:46:23 - @@ -208,7 +208,7 @@ check_shell: epp-ep_flags |= EXEC_INDIR; /* and set up the fake args list, for later */ - shellargp = malloc(4 * sizeof(char *), M_EXEC, M_WAITOK); + shellargp = mallocarray(4, sizeof(char *), M_EXEC, M_WAITOK); tmpsap = shellargp; *tmpsap = malloc(shellnamelen + 1, M_EXEC, M_WAITOK); strlcpy(*tmpsap++, shellname, shellnamelen + 1);
Re: use mallocarray in kern
On Sun, Jul 13, 2014 at 17:52, Theo de Raadt wrote: And some others from exec that follow a slightly different pattern. This is the pattern I have been following as well. As for the final diff, I've been giving up on the known constant scenario. It seems expensive. Meh. :) I think they can be changed back if necessary; in the mean time it makes it easier to see what's done and what remains. It is an extra register window on sparc and sparc64.
Re: faster malloc in threads
Anyway, I still like the idea, but I wonder if now right after the hackathon is the right time. But please continue experimenting with this during my vacation ;-) Changing the error message would be a good thing, to distinguish the various calls to munmap. Timing is bad. We need to fix the tree, and move towards release.
Re: trunk on RAMDISK_CD
Please don't send such mails if you didn't test yourself. Tree will lock right away. naddy's mpbios RAMDISK_CD mail reminded me that I have put trunk into RAMDISK_CD here for some time. Without, upgrading of machines with trunk is unecessarily hard, since, well, you won't get your trunk interface which typically has the IP(s) on it and you need to resort to manual network config w/ one of the underlaying interfaces. I can't for the sake of it remember whether I actually used the resulting bsd.rd on trunk'd machines (that's what you get for not mailing out the diff rigth away, sigh). Anybody has a chance to give this a spin on such a system? Would be really nice to have this in before release to make upgrades easier for trunk users. Index: sys/arch/amd64/conf/RAMDISK_CD === RCS file: /cvs/src/sys/arch/amd64/conf/RAMDISK_CD,v retrieving revision 1.142 diff -u -p -r1.142 RAMDISK_CD --- sys/arch/amd64/conf/RAMDISK_CD 14 Jul 2014 09:51:16 - 1.142 +++ sys/arch/amd64/conf/RAMDISK_CD 15 Jul 2014 10:41:29 - @@ -344,6 +344,7 @@ pseudo-device loop1 # network loopback #pseudo-devicesl 1 # CSLIP #pseudo-deviceppp 1 # PPP pseudo-device vlan# IEEE 802.1Q VLAN +pseudo-device trunk # Trunking support pseudo-device bpfilter 1 # packet filter pseudo-device rd 1 # ramdisk pseudo-device wsmux 2 Index: sys/arch/i386/conf/RAMDISK_CD === RCS file: /cvs/src/sys/arch/i386/conf/RAMDISK_CD,v retrieving revision 1.216 diff -u -p -r1.216 RAMDISK_CD --- sys/arch/i386/conf/RAMDISK_CD 12 Jul 2014 21:56:56 - 1.216 +++ sys/arch/i386/conf/RAMDISK_CD 15 Jul 2014 10:41:37 - @@ -414,6 +414,7 @@ pseudo-device loop1 # network loopback #pseudo-devicesl 1 # CSLIP #pseudo-deviceppp 1 # PPP pseudo-device vlan# IEEE 802.1Q VLAN +pseudo-device trunk # Trunking support pseudo-device bpfilter 1 # packet filter pseudo-device rd 1 # ramdisk pseudo-device wsmux 2 -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: DNS control port additions to /etc/services
On Tue, Jul 15, 2014 at 12:22:37PM +0100, Craig R. Skinner wrote: Suggestion of add NSD, Unbound BIND control ports to /etc/services: Makes sense to me. Anyone want to OK this? Index: etc/services === RCS file: /cvs/src/etc/services,v retrieving revision 1.87 diff -u -p -r1.87 services --- etc/services 12 Jul 2014 14:51:07 - 1.87 +++ etc/services 15 Jul 2014 11:17:31 - @@ -181,6 +181,8 @@ kerberos-adm 749/tcp # Kerberos 5 kad kerberos-adm749/udp # Kerberos 5 kadmin rsync 873/tcp # rsync server cddb888/tcp cddbp # Audio CD Database +named-rndc 953/tcp # Domain Name System (DNS) BIND RNDC Service +named-rndc 953/udp # Domain Name System (DNS) BIND RNDC Service imaps 993/tcp # imap4 protocol over TLS/SSL imaps 993/udp # imap4 protocol over TLS/SSL pop3s 995/tcp spop3 # pop3 protocol over TLS/SSL That means two more reserved ports are taken out of the bucket.
Re: DNS control port additions to /etc/services
Date: Tue, 15 Jul 2014 17:17:45 +0200 From: Antoine Jacoutot ajacou...@bsdfrog.org But be careful, this is not a user-editable file anymore, so we need to take into account that some stuffs that may not appear obvious to us may still be needed by people. That's a mistake. You're supposed to be able to add ports in there for custom software such that you can use getservbyname(3) and don't have to hardcode the port number in your code and be sure that something else doesn't camp out on that port because of port randomization. Give us time to figure out how this is going to work. This isn't some part of the tree that can be built in one step. sysmerge is going to change drastically in the next week. Wait and see.
Re: DNS control port additions to /etc/services
BIND uses TCP for the control socket, so if this does go in, please do not list the UDP one. Correct. For any service that runs on only one protocol, do not list the other protocol.
Re: LibreSSL and GOST crypto
On Wed, Jul 16, 2014 at 12:29 PM, Dmitry Eremin-Solenikov dbarysh...@gmail.com wrote: I have started looking into GOST (re)implementation for LibreSSL. I would like to know, how much do you want for LibreSSL to mimic the OpenSSL behaviour. I have been pointed that I did not formulate the question clearly. Would you prefer to have a static ENGINE thing built into the LibreSSL, providing 100% API compatibility with original ccgost implementation, or it would be better to have a cleaner well-integrated cryptosuite? It should be cleanly integrated. The ENGINE approach is silly.
Re: PATCH: further kernel malloc - mallocarray
I would really really prefer if we can keep these as const*const
conversions instead of const, const.
We will see performance losses from doing this operation at runtime.
On Wed, Jul 16, 2014 at 04:54:49AM +, Doug Hogan wrote:
+ if ((fake_table = mallocarray(3, sizeof(struct est_op),
It's not necessary to use mallocarray() for well known constants.
Few examples below.
--- sys/arch/i386/i386/est.c12 Jul 2014 18:44:41 - 1.43
+++ sys/arch/i386/i386/est.c15 Jul 2014 23:48:23 -
...
- if ((fake_table = malloc(sizeof(struct est_op) * 3, M_DEVBUF,
^^^
diff -u -p -d -r1.31 if_tsec.c
--- sys/arch/socppc/dev/if_tsec.c 12 Jul 2014 18:44:42 - 1.31
+++ sys/arch/socppc/dev/if_tsec.c 15 Jul 2014 23:48:25 -
@@ -909,7 +909,7 @@ tsec_up(struct tsec_softc *sc)
TSEC_NTXDESC * sizeof(struct tsec_desc), 8);
sc-sc_txdesc = TSEC_DMA_KVA(sc-sc_txring);
- sc-sc_txbuf = malloc(sizeof(struct tsec_buf) * TSEC_NTXDESC,
+ sc-sc_txbuf = mallocarray(TSEC_NTXDESC, sizeof(struct tsec_buf),
M_DEVBUF, M_WAITOK);
for (i = 0; i TSEC_NTXDESC; i++) {
txb = sc-sc_txbuf[i];
@@ -935,7 +935,7 @@ tsec_up(struct tsec_softc *sc)
TSEC_NRXDESC * sizeof(struct tsec_desc), 8);
sc-sc_rxdesc = TSEC_DMA_KVA(sc-sc_rxring);
- sc-sc_rxbuf = malloc(sizeof(struct tsec_buf) * TSEC_NRXDESC,
+ sc-sc_rxbuf = mallocarray(TSEC_NRXDESC, sizeof(struct tsec_buf),
M_DEVBUF, M_WAITOK);
for (i = 0; i TSEC_NRXDESC; i++) {
Index: sys/arch/sparc/dev/obio.c
===
RCS file: /cvs/src/sys/arch/sparc/dev/obio.c,v
retrieving revision 1.22
diff -u -p -d -r1.22 obio.c
--- sys/arch/sparc/dev/obio.c 5 Sep 2010 18:10:10 - 1.22
+++ sys/arch/sparc/dev/obio.c 15 Jul 2014 23:48:26 -
@@ -310,7 +310,7 @@ vmesattach(parent, self, args)
printf(\n);
if (vmeints == NULL) {
- vmeints = malloc(256 * sizeof(struct intrhand *), M_TEMP,
+ vmeints = mallocarray(256, sizeof(struct intrhand *), M_TEMP,
^^^
M_NOWAIT | M_ZERO);
if (vmeints == NULL)
panic(vmesattach: can't allocate intrhand);
@@ -332,7 +332,7 @@ vmelattach(parent, self, args)
printf(\n);
if (vmeints == NULL) {
- vmeints = malloc(256 * sizeof(struct intrhand *), M_TEMP,
+ vmeints = mallocarray(256, sizeof(struct intrhand *), M_TEMP,
^^^
M_NOWAIT | M_ZERO);
if (vmeints == NULL)
panic(vmelattach: can't allocate intrhand);
Index: sys/arch/sparc/dev/xd.c
===
RCS file: /cvs/src/sys/arch/sparc/dev/xd.c,v
retrieving revision 1.62
diff -u -p -d -r1.62 xd.c
--- sys/arch/sparc/dev/xd.c 11 Jul 2014 16:35:40 - 1.62
+++ sys/arch/sparc/dev/xd.c 15 Jul 2014 23:48:26 -
@@ -414,7 +414,7 @@ xdcattach(parent, self, aux)
/* Setup device view of DVMA address */
xdc-dvmaiopb = (struct xd_iopb *) ((u_long) xdc-iopbase - DVMA_BASE);
- xdc-reqs = malloc(XDC_MAXIOPB * sizeof(struct xd_iorq), M_DEVBUF,
+ xdc-reqs = mallocarray(XDC_MAXIOPB, sizeof(struct xd_iorq), M_DEVBUF,
^^^
M_NOWAIT | M_ZERO);
if (xdc-reqs == NULL)
panic(xdc malloc);
Index: sys/arch/sparc/dev/xy.c
===
RCS file: /cvs/src/sys/arch/sparc/dev/xy.c,v
retrieving revision 1.59
diff -u -p -d -r1.59 xy.c
--- sys/arch/sparc/dev/xy.c 11 Jul 2014 16:35:40 - 1.59
+++ sys/arch/sparc/dev/xy.c 15 Jul 2014 23:48:26 -
@@ -364,7 +364,7 @@ xycattach(parent, self, aux)
xyc-iopbase = tmp;
xyc-iopbase = dtmp; /* XXX TMP HACK */
xyc-dvmaiopb = (struct xy_iopb *) ((u_long)dtmp - DVMA_BASE);
- xyc-reqs = malloc(XYC_MAXIOPB * sizeof(struct xy_iorq), M_DEVBUF,
+ xyc-reqs = mallocarray(XYC_MAXIOPB, sizeof(struct xy_iorq), M_DEVBUF,
^^^
M_NOWAIT | M_ZERO);
if (xyc-reqs == NULL)
panic(xyc malloc);
Index: sys/arch/sparc64/dev/vdsk.c
===
RCS file: /cvs/src/sys/arch/sparc64/dev/vdsk.c,v
retrieving revision 1.39
diff -u -p -d -r1.39 vdsk.c
--- sys/arch/sparc64/dev/vdsk.c 12 Jul 2014 18:44:43 - 1.39
+++ sys/arch/sparc64/dev/vdsk.c 15 Jul 2014 23:48:27 -
@@ -298,7 +298,7 @@ vdsk_attach(struct device *parent, struc
printf(, can't
Re: improve srandomdev
On 07/13/2014 06:31 PM, Jean-Philippe Ouellet wrote:
On Sun, Jul 13, 2014 at 04:03:53PM +0200, Brent Cook wrote:
On Jul 13, 2014, at 3:58 PM, Ted Unangst t...@tedunangst.com wrote:
@@ -411,6 +404,9 @@ static long
random_l(void)
{
int32_t i;
+
+ if (use_arc4random)
+ return arc4random() 0x7fff;
return arc4random() % ((unsigned)RAND_MAX + 1) ?
No. RAND_MAX is for rand() not random().
From posix for random():
The random() function shall use a non-linear additive feedback
random-number generator employing a default state array size of
31 long integers to return successive pseudo-random numbers in
the range from 0 to 2^31 - 1.
This fwiw means that srandomdev needed fixing anyway, since a LFG needs
at least one of the elements in the stare array to be odd (or, since
random right shifts one position, at least one element with one of the
two lowest bits set).
That is false. Please read the actual code. The new variation uses
srandomdev() as an indicator that random() gets hooked direct to
arc4random. The guts of the algorithm are never used again.
The old code may have that issue. We will no longer case because this
fixes the issue. You can bring this to the attention of the FreeBSD
developers, who created this interface.
True, the chances of both happening are __ridiculously__ small, but hey,
aren't openbsd devs paranoid? :)
Was that neccessary?
Re: PATCH: further kernel malloc - mallocarray
From: Theo de Raadt dera...@cvs.openbsd.org Date: Wed, 16 Jul 2014 08:18:34 -0600 I would really really prefer if we can keep these as const*const conversions instead of const, const. Indeed, conversion to mallocarray only makes sence if one of the multiplication operands is a variable. That said, it is tricky. I've kept my eye out for one of the #define's to actually utilize a variable behind the scene. Haven't found one yet, but the potential is there.
Re: PATCH: further kernel malloc - mallocarray
static __inline int
MULT_OVERFLOWS(int x, int y)
{
const intmax_t max = 1UL sizeof(size_t) * 4;
return ((x = max || y = max) x 0 SIZE_MAX / x y);
}
(or maybe a macro version) in some public header someplace,
and associated assertions it where applicable.
The coding pattern currently chosen through a discussion by
Ted and myself is to convert:
l = n * s;
p = malloc(l, ...)
if (!p)
fail;
to either:
p = mallocarray(n, s, ...)
l = n * s;
if (!p)
fail;
or
p = mallocarray(n, s, ...)
if (!p)
fail;
l = n * s;
We think that is more clear than the addition of a add-on API
for integer overflow which people will avoid. The idea behind
mallocarray() is that it is in-your-face -- we want to develop
the mindset that any malloc() gets looked at from the perspective
of int overflow right in it's arguments.
Re: improve srandomdev
That is false. Please read the actual code. The new variation uses srandomdev() as an indicator that random() gets hooked direct to arc4random. The guts of the algorithm are never used again. I did, that's why fwiw and needed, as in look, you fixed a bug without noticing. Oh, ok. Actually in OpenBSD it does not matter much. Since we have had arc4random() since 1996, we have had plenty of time to clean the tree. A review found only a handful of games, which had not been converted specifically because they have the old-world but I want to cheat or replay using the same seed behaviour.
Re: lynx: disable old protocols
On Wed, 2014-07-16 at 13:56 -0500, patric conant wrote: I'd also like to point out that Shawn has broken the social contract here, it's well known that it's generally considered rude to direct developers, in this forum. Every single free or open-source software project I have ever used has been shaped by user feedback. Most take it seriously when users say they still use functionality that's being slated for removal. So Patric, you can take this social contract of yours and shove it up your ass. I don't recognize it as anything but toilet paper. Shawn -- leave this list.
Re: lynx: disable old protocols
For the rest of us who prefer to use software instead of demanding changes, this simply means using OpenBSD in a strictly-isolated environment becomes a bit more difficult. This statement makes no sense. Why would you strictly isolate the environment? Because you want security. In that case, have you read the code for lynx? I'm still not willing to use Linux LiveCDs in certain environments for the most part, and I'll just get used to having the ports I absolutely need (probably elinks or Firefox, at this point, not lynx!) on a pre-burned CD. Piece of cake. Related question: what happened to putting the most commonly-used pkgs on the CDs? Did we just run out of room? My 5.5 CD set has a grand total of about 8 packages IIRC. Yes, we run out, actually on a regular basis. I don't think people realize how much effort goes into re-fitting things. Most releases it is simple, but other releases we suddenly must revamp the layout pretty substantially. It isn't some amateur 1 hour effort. I do not know yet what happens for 5.6, I have not repeated the 5.5 layout yet. pkg_add uses signify keys now. You can use the internet to get packages. They do not need to be on the release CD. Most of us get that you're all hacking on OpenBSD primarily to scratch a personal itch and secondarily to provide something good to the rest of the world. I recall reading somewhere a summary of the tech@ attitude, which boiled down to if you can use our code, great, otherwise go away and stop bothering us. Thank you.
Re: Miscellaneous LibreSSL portability fixes
On 17/07/14 04:26, Bob Beck wrote: Steve, sorry, but GNU/kFreeBSD is not going to happen right now. We are too busy with other things. I understand, actually I wasn't asking for that. I think having lots of platform-specific implementations would be unclean, I was only hoping the existing getentropy_linux could become more generic so that it works on unthought-of platforms. Hang on, please don't make getentropy_linux.c more generic. It is already more complex than it should be. I recommend you cut bits from all of the versions you see, and create a new file for your system; you will be able to diff the results to see if you are on the right track. Then be sure to instrument the code to do some basic analysis of the hash input in the fallback function, and think about the methodology. Once you get closer and show me your candidate source file, I can send you a piece of code that will be helpful, and some advice for adding more fallback sources. But let me worry about porting to GNU/kFreeBSD. The rest of LibreSSL code compiled flawlessly so I already had it up and running. If I find a neat, unobtrusive way to do this I'll send patches for consideration. The process is: 1. POSIX / ANSI first, with OpenBSD used as a baseline to avoid walking into fanatical standards following which will (ironically) hurt future portability 2. Compatibility with a narrow mix of common platforms where we hope to find more exceedingly skilled people who will help 3. Then we'll see.
Re: Only what you need
Something that has been in my eye for a while; how about those users and groups? $ cat /etc/passwd|wc -l 56 $ cat /etc/group |wc -l 75 Maybe one group for write access to /var, one for /etc, etc? Or we could run them all as root.
Re: [DIFF] sftp-server.8, sshd_config.5 after syslog_r change
Unfortunately, no. The ssh manual pages are also used by the -portable effort. We do not bother documenting these divergences; there is little harm. Actually you could submit a new diff which suggest that logging might need a /dev/log setup. If written carefully to cover both kinds of systems, that would be accepted. is this correct to reflect syslog_r(3) change? I tested chrooted internal-sftp without /dev/log in the chroot and it was logging fine. j. Index: sftp-server.8 === RCS file: /cvs/src/usr.bin/ssh/sftp-server.8,v retrieving revision 1.25 diff -u -p -r1.25 sftp-server.8 --- sftp-server.8 14 Oct 2013 14:18:56 - 1.25 +++ sftp-server.8 18 Jul 2014 20:58:23 - @@ -139,16 +139,6 @@ Sets an explicit to be applied to newly-created files and directories, instead of the user's default mask. .El -.Pp -For logging to work, -.Nm -must be able to access -.Pa /dev/log . -Use of -.Nm -in a chroot configuration therefore requires that -.Xr syslogd 8 -establish a logging socket inside the chroot directory. .Sh SEE ALSO .Xr sftp 1 , .Xr ssh 1 , Index: sshd_config.5 === RCS file: /cvs/src/usr.bin/ssh/sshd_config.5,v retrieving revision 1.175 diff -u -p -r1.175 sshd_config.5 --- sshd_config.5 15 Jul 2014 15:54:14 - 1.175 +++ sshd_config.5 18 Jul 2014 20:58:24 - @@ -344,12 +344,7 @@ devices. For file transfer sessions using .Dq sftp , no additional configuration of the environment is necessary if the -in-process sftp server is used, -though sessions which use logging do require -.Pa /dev/log -inside the chroot directory (see -.Xr sftp-server 8 -for details). +in-process sftp server is used. .Pp The default is not to .Xr chroot 2 .
Re: res_random.c: 'static' is not at beginning of declaration
revision 1.21 date: 2014/07/20 04:22:34; author: guenther; state: Exp; lines: +2 -2; commitid: x7aBoxPF8nZvW5Z0; From ISO/IEC 9899:1999 and 9899:201x, 6.11.5 - Storage-class specifiers: The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature. Diff from Jean-Philippe Ouellet (jean-philippe (at) ouellet.biz) This got fixed a few days ago.
Re: PATCH: overflow behavior in malloc(9)
On Tue, Jul 22, 2014 at 21:21, Doug Hogan wrote: On Tue, Jul 22, 2014 at 02:51:17AM -0400, Jean-Philippe Ouellet wrote: That is misleading in the M_CANFAIL case. I'm not terribly good at wording things, but I suggest something more like this instead: Hmm I think it's only misleading in the M_CANFAIL case. I think this diff makes it a little more complex than it needs to be. What do you think about leaving the malloc option section as-is and instead explain how mallocarray() operates before it calls malloc()? Something along these lines: mallocarray(9) is a wrapper around malloc(9) that checks for overflow. If arithmetic overflow is detected, it returns NULL when M_CANFAIL is enabled or else calls panic(). Otherwise, it has the same behavior as malloc. Does that work? This is a kernel interface. I think some expectation of read the source is not unwarranted. The man page should tell you what it does and why you want it, but I'm not convinced all internal behaviors need be documented. That's my view, anyway. Handholding can go only so far. Beyond that, the manual page stops being concise.
Re: [PATCH, libressl] discuss: removal of padding extension?
Quick background: Some router firmwares from F5 have a bug that they fail if the SSL handshake is between 256 and 511 bytes. Following up that openssl and other major ssl implementations introduced a TLS padding extension that does nothing else than padding the handshake if it is between these sizes. hmm. the workaround isn't particularly intrusive imo. also, while our policy has been minimal workarounds, i think that applies to the host operating system. interop compat is a different beast. Indeed. Removal of this code would require proof that it causes no harm. I am quite frankly sick of being told that we are removing code we don't understand, when it is not true. In this case, we have no idea how many broken F5's there are out there, so there is no reason to remove this code. Proving the case would be up to you Hanno. You can start by trying to suggest that the OpenSSL folk should remove it...
Re: [DIFF] sftp-server.8, sshd_config.5 after syslog_r change
Unfortunately, no. The ssh manual pages are also used by the -portable effort. We do not bother documenting these divergences; there is little harm. Actually you could submit a new diff which suggest that logging might need a /dev/log setup. If written carefully to cover both kinds of systems, that would be accepted. The mention of sendsyslog is not acceptable. When this man page shows up on some other system, it will be an Xr pointing to nowhere. The information is too specific. Frankly, noone will care. Old systems will continue doing what they have, which is the provided advice to have /dev/log in the chroot space. In attempting to remove this advice for OpenBSD-only, you are just plain being too specific. Meaning if someone leaves /dev/log in an OpenBSD chroot space, nothing at all is harmed. Index: sftp-server.8 === RCS file: /cvs/src/usr.bin/ssh/sftp-server.8,v retrieving revision 1.25 diff -u -r1.25 sftp-server.8 --- sftp-server.8 14 Oct 2013 14:18:56 - 1.25 +++ sftp-server.8 28 Jul 2014 15:14:45 - @@ -140,15 +140,21 @@ user's default mask. .El .Pp -For logging to work, +On many systems, .Nm must be able to access -.Pa /dev/log . -Use of +.Pa /dev/log +for logging to work, and use of .Nm in a chroot configuration therefore requires that .Xr syslogd 8 establish a logging socket inside the chroot directory. +This is not needed on systems implementing the +.Xr syslog 3 +family of functions in terms of a +.Xr sendsyslog 2 +system call, for example +.Ox . .Sh SEE ALSO .Xr sftp 1 , .Xr ssh 1 , Index: sshd_config.5 === RCS file: /cvs/src/usr.bin/ssh/sshd_config.5,v retrieving revision 1.175 diff -u -r1.175 sshd_config.5 --- sshd_config.5 15 Jul 2014 15:54:14 - 1.175 +++ sshd_config.5 28 Jul 2014 15:14:45 - @@ -345,9 +345,9 @@ .Dq sftp , no additional configuration of the environment is necessary if the in-process sftp server is used, -though sessions which use logging do require +though sessions which use logging may require .Pa /dev/log -inside the chroot directory (see +inside the chroot directory on some operating systems (see .Xr sftp-server 8 for details). .Pp
Re: /dev/crypto removal (3bis): DTYPE_CRYPTO
I don't know if we recycle them somehow, but just in case... --- sys/sys/file.h +++ sys/sys/file.h ... -#defineDTYPE_CRYPTO5 /* crypto */ +/* was define DTYPE_CRYPTO5 */ When it goes, this is the way to document it, yep. ...but you better delete the code in usr.bin/fstat/fstat.c and usr.sbin/pstat/pstat.c before that. I also approve of this way of cleaning up /dev/crypto. Just do make builds after every change.
Re: PATCH: rtsol support for RA DNS options
I didn't realize autoconf was in in the kernel and plumbed up through ifconfig. Centralizing this stuff seems like a cleaner way to do it than having rtsol/rtsold, in which case this patch is barking up the wrong tree. Yes, you are working in an old tree. Has any thought been given to pushing (or pulling) the DNS-related RA options up into the resolver configuration? A satisfactory design does not yet exist. It would be nice if dhclient and the no-dynamic environments had some arbitration scheme for placing the information in the the file, where libc picks it up. Something clever, but robust. Not overdesigned.
Re: PATCH: rtsol support for RA DNS options
One way to manage the file is the openresolv script I mentioned earlier. The idea is that entities like dhclient invoke it with resolver information they want to use and the script merges requests from multiple sources. I do not understand how this solution will practically work. Seeing as it is a script, over time it will bloat into an unmanageable layer dealing with changes between hand-edited static files, the dhclient scenario, and now the ipv6 scenario. Sure, your sample is 3 lines long. In a year, it will be pages long of complicated. I also don't think you understand that dhclient has been substantially modified to NOT USE A SCRIPT.
Re: chmod.c undefined behavior
I mght be wrong, but why not just initialize to NULL? I am watching this thread to spot people who should never be OpenBSD developers...
Re: chmod.c undefined behavior
That main function is good, standard style. Unnecessary goto, variables defined far away from where they are used, monster function, variables are not commented what they do, not all functions are commented what they do.. To me, it looks like that there is no intention to optimize readability and testability. Instead it looks like there is put effort to minimize amount of functions or something. It has one small getopt(3) loop, decrements argc/argv, has one small codeblock to handle arguments for each variant of the utility, and one concise fts(3) main loop to handle files, and finally a one-liner for error handling. It would be better if they all are put to separate functions. That is the whole point in functions, to put task to single program fragment. So what's the point? You can't *calculate* whether something is readable for a *human*, and that's what matters. There are measured human factors, example size of working memory. If there is measured magic constants, it is possible to calculate what is somewhat better or worse. Something to aim for: -Less linearly independent paths in module -High cohesion -Low coupling These are basics. It also matters a lot for testability. Less independent paths means less test cases. It really sounds like you could be more useful elsewhere. Like maybe helping to improve GNU echo.
Re: chmod.c undefined behavior
I have about million lines of build and other errors under review where I have found anomalies. Some of them seems to be errors in OpenBSD, most of them are errors in code. Yet somehow out of those million you decided to send in a patch which introduced a bug. I believe I know your type.
sdmmc resume (newer Ricoh sdhc chipsets)
Newish Ricoh sdhc chipsets initialize into a high speed mode that is
not compatible with our existing sdmmc stack. At activate we push
the chipset into the older modes; we need to do the same at resume
time.
Fixes the x230.
Index: sdhc_pci.c
===
RCS file: /cvs/src/sys/dev/pci/sdhc_pci.c,v
retrieving revision 1.15
diff -u -p -u -r1.15 sdhc_pci.c
--- sdhc_pci.c 13 Jul 2014 23:10:23 - 1.15
+++ sdhc_pci.c 26 Sep 2014 10:27:40 -
@@ -48,17 +48,23 @@
struct sdhc_pci_softc {
struct sdhc_softc sc;
+ pci_chipset_tag_t sc_pc;
+ pcitag_t sc_tag;
+ pcireg_t sc_id;
void *sc_ih;
};
intsdhc_pci_match(struct device *, void *, void *);
void sdhc_pci_attach(struct device *, struct device *, void *);
+intsdhc_pci_activate(struct device *, int);
+
+void sdhc_pci_conf_write(pci_chipset_tag_t, pcitag_t, int, uint8_t);
void sdhc_takecontroller(struct pci_attach_args *);
-void sdhc_pci_conf_write(struct pci_attach_args *, int, uint8_t);
+void sdhc_ricohfix(struct sdhc_pci_softc *);
struct cfattach sdhc_pci_ca = {
sizeof(struct sdhc_pci_softc), sdhc_pci_match, sdhc_pci_attach,
- NULL, sdhc_activate
+ NULL, sdhc_pci_activate
};
int
@@ -105,6 +111,10 @@ sdhc_pci_attach(struct device *parent, s
bus_size_t size;
u_int32_t caps = 0;
+ sc-sc_pc = pa-pa_pc;
+ sc-sc_tag = pa-pa_tag;
+ sc-sc_id = pa-pa_id;
+
/* Some TI controllers needs special treatment. */
if (PCI_VENDOR(pa-pa_id) == PCI_VENDOR_TI
PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_TI_PCI7XX1_SD
@@ -118,20 +128,8 @@ sdhc_pci_attach(struct device *parent, s
/* Some RICOH controllers need to be bumped into the right mode. */
if (PCI_VENDOR(pa-pa_id) == PCI_VENDOR_RICOH
- PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_RICOH_R5U823) {
- /* Enable SD2.0 mode. */
- sdhc_pci_conf_write(pa, SDHC_PCI_MODE_KEY, 0xfc);
- sdhc_pci_conf_write(pa, SDHC_PCI_MODE, SDHC_PCI_MODE_SD20);
- sdhc_pci_conf_write(pa, SDHC_PCI_MODE_KEY, 0x00);
-
- /*
-* Some SD/MMC cards don't work with the default base
-* clock frequency of 200MHz. Lower it to 50Hz.
-*/
- sdhc_pci_conf_write(pa, SDHC_PCI_BASE_FREQ_KEY, 0x01);
- sdhc_pci_conf_write(pa, SDHC_PCI_BASE_FREQ, 50);
- sdhc_pci_conf_write(pa, SDHC_PCI_BASE_FREQ_KEY, 0x00);
- }
+ PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_RICOH_R5U823)
+ sdhc_ricohfix(sc);
if (pci_intr_map(pa, ih)) {
printf(: can't map interrupt\n);
@@ -185,6 +183,27 @@ sdhc_pci_attach(struct device *parent, s
}
}
+int
+sdhc_pci_activate(struct device *self, int act)
+{
+ struct sdhc_pci_softc *sc = (struct sdhc_pci_softc *)self;
+ int rv;
+
+ switch (act) {
+ case DVACT_SUSPEND:
+ rv = sdhc_activate(self, act);
+ break;
+ case DVACT_RESUME:
+ rv = sdhc_activate(self, act);
+ sdhc_ricohfix(sc);
+ break;
+ default:
+ rv = sdhc_activate(self, act);
+ break;
+ }
+ return (rv);
+}
+
void
sdhc_takecontroller(struct pci_attach_args *pa)
{
@@ -207,12 +226,29 @@ sdhc_takecontroller(struct pci_attach_ar
}
void
-sdhc_pci_conf_write(struct pci_attach_args *pa, int reg, uint8_t val)
+sdhc_ricohfix(struct sdhc_pci_softc *sc)
+{
+ /* Enable SD2.0 mode. */
+ sdhc_pci_conf_write(sc-sc_pc, sc-sc_tag, SDHC_PCI_MODE_KEY, 0xfc);
+ sdhc_pci_conf_write(sc-sc_pc, sc-sc_tag, SDHC_PCI_MODE,
SDHC_PCI_MODE_SD20);
+ sdhc_pci_conf_write(sc-sc_pc, sc-sc_tag, SDHC_PCI_MODE_KEY, 0x00);
+
+ /*
+* Some SD/MMC cards don't work with the default base
+* clock frequency of 200MHz. Lower it to 50Hz.
+*/
+ sdhc_pci_conf_write(sc-sc_pc, sc-sc_tag, SDHC_PCI_BASE_FREQ_KEY,
0x01);
+ sdhc_pci_conf_write(sc-sc_pc, sc-sc_tag, SDHC_PCI_BASE_FREQ, 50);
+ sdhc_pci_conf_write(sc-sc_pc, sc-sc_tag, SDHC_PCI_BASE_FREQ_KEY,
0x00);
+}
+
+void
+sdhc_pci_conf_write(pci_chipset_tag_t pc, pcitag_t tag, int reg, uint8_t val)
{
pcireg_t tmp;
- tmp = pci_conf_read(pa-pa_pc, pa-pa_tag, reg ~0x3);
+ tmp = pci_conf_read(pc, tag, reg ~0x3);
tmp = ~(0xff ((reg 0x3) * 8));
tmp |= (val ((reg 0x3) * 8));
- pci_conf_write(pa-pa_pc, pa-pa_tag, reg ~0x3, tmp);
+ pci_conf_write(pc, tag, reg ~0x3, tmp);
}
Re: sdmmc resume (newer Ricoh sdhc chipsets)
Oops, only do the ricoh fixup on the specific ricoh chips.
Index: sdhc_pci.c
===
RCS file: /cvs/src/sys/dev/pci/sdhc_pci.c,v
retrieving revision 1.15
diff -u -p -u -r1.15 sdhc_pci.c
--- sdhc_pci.c 13 Jul 2014 23:10:23 - 1.15
+++ sdhc_pci.c 26 Sep 2014 10:27:40 -
@@ -48,17 +48,23 @@
struct sdhc_pci_softc {
struct sdhc_softc sc;
+ pci_chipset_tag_t sc_pc;
+ pcitag_t sc_tag;
+ pcireg_t sc_id;
void *sc_ih;
};
intsdhc_pci_match(struct device *, void *, void *);
void sdhc_pci_attach(struct device *, struct device *, void *);
+intsdhc_pci_activate(struct device *, int);
+
+void sdhc_pci_conf_write(pci_chipset_tag_t, pcitag_t, int, uint8_t);
void sdhc_takecontroller(struct pci_attach_args *);
-void sdhc_pci_conf_write(struct pci_attach_args *, int, uint8_t);
+void sdhc_ricohfix(struct sdhc_pci_softc *);
struct cfattach sdhc_pci_ca = {
sizeof(struct sdhc_pci_softc), sdhc_pci_match, sdhc_pci_attach,
- NULL, sdhc_activate
+ NULL, sdhc_pci_activate
};
int
@@ -105,6 +111,10 @@ sdhc_pci_attach(struct device *parent, s
bus_size_t size;
u_int32_t caps = 0;
+ sc-sc_pc = pa-pa_pc;
+ sc-sc_tag = pa-pa_tag;
+ sc-sc_id = pa-pa_id;
+
/* Some TI controllers needs special treatment. */
if (PCI_VENDOR(pa-pa_id) == PCI_VENDOR_TI
PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_TI_PCI7XX1_SD
@@ -118,20 +128,8 @@ sdhc_pci_attach(struct device *parent, s
/* Some RICOH controllers need to be bumped into the right mode. */
if (PCI_VENDOR(pa-pa_id) == PCI_VENDOR_RICOH
- PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_RICOH_R5U823) {
- /* Enable SD2.0 mode. */
- sdhc_pci_conf_write(pa, SDHC_PCI_MODE_KEY, 0xfc);
- sdhc_pci_conf_write(pa, SDHC_PCI_MODE, SDHC_PCI_MODE_SD20);
- sdhc_pci_conf_write(pa, SDHC_PCI_MODE_KEY, 0x00);
-
- /*
-* Some SD/MMC cards don't work with the default base
-* clock frequency of 200MHz. Lower it to 50Hz.
-*/
- sdhc_pci_conf_write(pa, SDHC_PCI_BASE_FREQ_KEY, 0x01);
- sdhc_pci_conf_write(pa, SDHC_PCI_BASE_FREQ, 50);
- sdhc_pci_conf_write(pa, SDHC_PCI_BASE_FREQ_KEY, 0x00);
- }
+ PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_RICOH_R5U823)
+ sdhc_ricohfix(sc);
if (pci_intr_map(pa, ih)) {
printf(: can't map interrupt\n);
@@ -185,6 +183,27 @@ sdhc_pci_attach(struct device *parent, s
}
}
+int
+sdhc_pci_activate(struct device *self, int act)
+{
+ struct sdhc_pci_softc *sc = (struct sdhc_pci_softc *)self;
+ int rv;
+
+ switch (act) {
+ case DVACT_SUSPEND:
+ rv = sdhc_activate(self, act);
+ break;
+ case DVACT_RESUME:
+ rv = sdhc_activate(self, act);
+ sdhc_ricohfix(sc);
+ break;
+ default:
+ rv = sdhc_activate(self, act);
+ break;
+ }
+ return (rv);
+}
+
void
sdhc_takecontroller(struct pci_attach_args *pa)
{
@@ -207,12 +226,29 @@ sdhc_takecontroller(struct pci_attach_ar
}
void
-sdhc_pci_conf_write(struct pci_attach_args *pa, int reg, uint8_t val)
+sdhc_ricohfix(struct sdhc_pci_softc *sc)
+{
+ /* Enable SD2.0 mode. */
+ sdhc_pci_conf_write(sc-sc_pc, sc-sc_tag, SDHC_PCI_MODE_KEY, 0xfc);
+ sdhc_pci_conf_write(sc-sc_pc, sc-sc_tag, SDHC_PCI_MODE,
SDHC_PCI_MODE_SD20);
+ sdhc_pci_conf_write(sc-sc_pc, sc-sc_tag, SDHC_PCI_MODE_KEY, 0x00);
+
+ /*
+* Some SD/MMC cards don't work with the default base
+* clock frequency of 200MHz. Lower it to 50Hz.
+*/
+ sdhc_pci_conf_write(sc-sc_pc, sc-sc_tag, SDHC_PCI_BASE_FREQ_KEY,
0x01);
+ sdhc_pci_conf_write(sc-sc_pc, sc-sc_tag, SDHC_PCI_BASE_FREQ, 50);
+ sdhc_pci_conf_write(sc-sc_pc, sc-sc_tag, SDHC_PCI_BASE_FREQ_KEY,
0x00);
+}
+
+void
+sdhc_pci_conf_write(pci_chipset_tag_t pc, pcitag_t tag, int reg, uint8_t val)
{
pcireg_t tmp;
- tmp = pci_conf_read(pa-pa_pc, pa-pa_tag, reg ~0x3);
+ tmp = pci_conf_read(pc, tag, reg ~0x3);
tmp = ~(0xff ((reg 0x3) * 8));
tmp |= (val ((reg 0x3) * 8));
- pci_conf_write(pa-pa_pc, pa-pa_tag, reg ~0x3, tmp);
+ pci_conf_write(pc, tag, reg ~0x3, tmp);
}
Re: maketz.sh problems with distrib build
so is there a better way to just build a kernel? i'm not going to build a whole release just for one kernel, especially when experimenting. and i mean a RAMDISK kernel. i think its great the things i can do with openbsd, even when it is not what is intended. tough. I'm sorry, but this is the build process that makes snapshots. It serves that purpose and is designed for that. It is not carveable in the way you want to use it. It will not be changed. You are on your own, really.
Re: groupdel(8): preserve `+' line
That utility is grossly disgusting. It's a pity we can't delete it completely [...] Why not? :-)
