Convert hand-rolled lists to TAILQ_* in ac(8)
Hi,
I've attempted to convert the hand-rolled linked lists over to
TAILQ. I've tested this briefly and it seems to work okay.
Does it look good? Let me know if I need to rework anything.
===
RCS file: /cvs/src/usr.sbin/ac/ac.c,v
retrieving revision 1.22
diff -u -p -r1.22 ac.c
--- ac.c31 Aug 2012 19:57:12 - 1.22
+++ ac.c5 Nov 2014 11:30:46 -
@@ -25,9 +25,11 @@
* SUCH DAMAGE.
*/
-#include sys/types.h
#include sys/file.h
+#include sys/queue.h
#include sys/time.h
+#include sys/types.h
+
#include err.h
#include errno.h
#include pwd.h
@@ -40,28 +42,28 @@
/*
* this is for our list of currently logged in sessions
*/
-struct utmp_list {
- struct utmp_list *next;
+struct utmp_entry {
struct utmp usr;
+ TAILQ_ENTRY(utmp_entry) next;
};
/*
* this is for our list of users that are accumulating time.
*/
-struct user_list {
- struct user_list *next;
+struct user_entry {
charname[UT_NAMESIZE+1];
time_t secs;
+ TAILQ_ENTRY(user_entry) next;
};
/*
* this is for chosing whether to ignore a login
*/
-struct tty_list {
- struct tty_list *next;
+struct tty_entry {
charname[UT_LINESIZE+3];
size_t len;
int ret;
+ TAILQ_ENTRY(tty_entry) next;
};
/*
@@ -70,8 +72,9 @@ struct tty_list {
static time_t Total = 0;
static time_t FirstTime = 0;
static int Flags = 0;
-static struct user_list *Users = NULL;
-static struct tty_list *Ttys = NULL;
+static TAILQ_HEAD(Utmphead, utmp_entry) Utmphead;
+static TAILQ_HEAD(Userhead, user_entry) Userhead;
+static TAILQ_HEAD(Ttyhead, tty_entry) Ttyhead;
#defineAC_W1 /* not _PATH_WTMP */
#defineAC_D2 /* daily totals (ignore
-p) */
@@ -88,14 +91,13 @@ int ac(FILE *);
void add_tty(char *);
intdo_tty(char *);
FILE *file(char *);
-struct utmp_list *log_in(struct utmp_list *, struct utmp *);
-struct utmp_list *log_out(struct utmp_list *, struct utmp *);
-inton_console(struct utmp_list *);
+void log_in(struct utmp *);
+void log_out(struct utmp *);
+inton_console(void);
void show(char *, time_t);
-void show_today(struct user_list *, struct utmp_list *,
- time_t);
-void show_users(struct user_list *);
-struct user_list *update_user(struct user_list *, char *, time_t);
+void show_today(time_t);
+void show_users(void);
+void update_user(char *, time_t);
void usage(void);
/*
@@ -119,12 +121,12 @@ file(char *name)
void
add_tty(char *name)
{
- struct tty_list *tp;
+ struct tty_entry *tp;
char *rcp;
Flags |= AC_T;
- if ((tp = malloc(sizeof(struct tty_list))) == NULL)
+ if ((tp = malloc(sizeof(sizeof(*tp == NULL)
err(1, malloc);
tp-len = 0;/* full match */
tp-ret = 1;/* do if match */
@@ -137,8 +139,7 @@ add_tty(char *name)
*rcp = '\0';
tp-len = strlen(tp-name); /* match len bytes only */
}
- tp-next = Ttys;
- Ttys = tp;
+ TAILQ_INSERT_HEAD(Ttyhead, tp, next);
}
/*
@@ -147,10 +148,10 @@ add_tty(char *name)
int
do_tty(char *name)
{
- struct tty_list *tp;
+ struct tty_entry *tp;
int def_ret = 0;
- for (tp = Ttys; tp != NULL; tp = tp-next) {
+ TAILQ_FOREACH(tp, Ttyhead, next) {
if (tp-ret == 0) /* specific don't */
def_ret = 1;/* default do */
if (tp-len != 0) {
@@ -167,31 +168,30 @@ do_tty(char *name)
/*
* update user's login time
*/
-struct user_list *
-update_user(struct user_list *head, char *name, time_t secs)
+void
+update_user(char *name, time_t secs)
{
- struct user_list *up;
+ struct user_entry *up;
- for (up = head; up != NULL; up = up-next) {
+ TAILQ_FOREACH(up, Userhead, next) {
if (strncmp(up-name, name, sizeof (up-name) - 1) == 0) {
up-secs += secs;
Total += secs;
- return head;
+ return;
}
}
/*
* not found so add new user unless specified users only
*/
if (Flags AC_U)
- return head;
+ return;
- if ((up = malloc(sizeof(struct user_list))) == NULL)
+ if ((up = malloc(sizeof(*up))) == NULL)
err(1, malloc);
- up-next = head;
strlcpy(up-name, name, sizeof (up-name));
up-secs
Re: new: libowfat
On Sun, Nov 02, 2014 at 09:40:20AM +, Stuart Henderson wrote: On 2014/11/01 21:22, Jan Klemkow wrote: Hi, this is a new port of Fefe's reimplementation of libdjb. This library is a reimplementation of libdjb. It contains several wrappers for socket functions, mkfifo, opendir, wait, an abstraction around errno, Unix signal functions, memory and string handling. Mainly it is a dependency of gatling. gatling is a fast http/file server which will follow soon. If anything is wrong with this port, please tell me. Upstream is informed about the little dependency fix of the makefile. Thanks, Jan - PLIST needs an @mandir annotation for the manual directory (see tcl for an example) done - say which version of GPL is used (e.g. GPLv2 only, GPLv2+ (v2 or newer), GPLv3 only, GPLv3+, etc). done - your COMMENT is only useful for people who know what libdjb is, better to just say what the library is for (I would ignore libdjb in COMMENT for space reasons, just mention in DESCR) done - whitespace nitpicking: NO_TEST =spacetab please just use tab done - I would prefer to override the Makefile variables using MAKE_FLAGS rather than patching (then when upstream fix the dependency, the patch can be removed completely) I used FAKE_FLAGS, cause it is just used during the installation. Thanks, Jan libowfat.tar.gz Description: application/tar-gz
Re: iked responds with esp over external ips.
On 4 November 2014 17:06, Martin Larsson martin.larss...@gmail.com wrote: Hello! I've setup a tunnel between OpenBSD 5.6 using iked and an openwrt router running strongswan. The tunnel works great with ping and other traffic but traffic between the two external ip's dies. This is a site-to-site connection and nothing fancy. iked.conf on OpenBSD. ikev2 esp from $10.11.12.0/24 to $194.168.4.0/24 peer $tcgw srcid sippan.se # ipsecctl -sa FLOWS: flow esp in from 192.168.4.0/24 to 10.11.12.0/24 peer 82.17.12.21 srcid FQDN/sippan.se dstid FQDN/sswan.sippan.se type use flow esp out from 10.11.12.0/24 to 192.168.4.0/24 peer 82.17.12.21 srcid FQDN/sippan.se dstid FQDN/sswan.sippan.se type require flow esp out from ::/0 to ::/0 type deny SAD: esp tunnel from 82.17.12.21 to 130.51.23.4 spi 0x67483925 auth hmac-sha1 enc aes esp tunnel from 130.51.23.4 to 82.17.12.21 spi 0xcf1f39d1 auth hmac-sha1 enc aes # netstat -nr Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface default130.51.23.4 UGS 10 30430256 - 8 em0 10/8 link#5 UC 10 - 4 vether0 10.11.12.13fe:e1:ba:d0:d6:1c UHLl 01 - 1 lo0 10.255.255.255 link#5 UHLc 3 570 - 4 vether0 82.17.12.21 130.51.23.4 UGHD 0 30430251 - L 56 em0 127/8 127.0.0.1 UGRS 00 32768 8 lo0 127.0.0.1 127.0.0.1 UH 16 32768 4 lo0 194.48.213.128/27 link#1 UC 10 - 4 em0 130.51.23.4 00:00:cd:19:95:16 UHLc 20 - 4 em0 130.51.23.4 00:02:b3:aa:cc:c3 HLl00 - 1 lo0 224/4 127.0.0.1 URS00 32768 8 lo0 Internet6: -removed, dont use it- Encap: Source Port DestinationPort Proto SA(Address/Proto/Type/Direction) 192.168.4/24 0 10.11.12/240 0 82.17.12.21/esp/use/in 10.11.12/240 192.168.4/24 0 0 82.17.12.21/esp/require/out default0 default 0 0 none/esp/deny/out # tcpdump on openbsd while trying to connect with ssh to the external ip of the OpenBSD host from the exernal ip of the other end. # tcpdump host 82.17.12.21 tcpdump: listening on em0, link-type EN10MB tcpdump: WARNING: compensating for unaligned libpcap packets 16:49:55.539903 egget.priv.lamest.se.54158 loller.sippan.se.ssh: S 2729317717:2729317717(0) win 8192 mss 1460,nop,wscale 8,nop,nop,sackOK (DF) 16:49:55.539932 loller.sippan.se.ssh egget.priv.lamest.se.54158: S 2317435827:2317435827(0) ack 2729317718 win 16384 mss 1240,nop,nop,sackOK,nop,wscale 3 16:49:55.545936 egget.priv.lamest.se.54158 loller.sippan.se.ssh: . ack 1 win 256 (DF) 16:49:55.553927 esp loller.sippan.se egget.priv.lamest.se spi 0xcf1f39d1 seq 190 len 100 16:50:01.553883 esp loller.sippan.se egget.priv.lamest.se spi 0xcf1f39d1 seq 191 len 100 16:50:05.977468 esp egget.priv.lamest.se loller.sippan.se spi 0x67483925 seq 127 len 84 (DF) 16:50:05.977519 esp loller.sippan.se egget.priv.lamest.se spi 0xcf1f39d1 seq 192 len 84 # tcpdump on enc0 while trying ssh and https tcpdump: listening on enc0, link-type ENC tcpdump: WARNING: compensating for unaligned libpcap packets 17:01:01.578622 (authentic,confidential): SPI 0xc31749f4: loller.sippan.se.ssh egget.priv.lamest.se.54158: R 2317435850:2317435850(0) ack 2729317718 win 0 (encap) 17:01:05.786123 (authentic,confidential): SPI 0xc31749f4: loller.sippan.se.ssh egget.priv.lamest.se.54792: P 3813334764:3813334785(21) ack 2711749548 win 2170 (encap) 17:01:05.968654 (authentic,confidential): SPI 0xc31749f4: loller.sippan.se.https egget.priv.lamest.se.54793: P 3540908942:3540909100(158) ack 1840586787 win 2170 (encap) 17:01:06.265543 (authentic,confidential): SPI 0xc31749f4: loller.sippan.se.https egget.priv.lamest.se.54793: . ack 1 win 2170 (encap) 17:01:06.876165 (authentic,confidential): SPI 0xc31749f4: loller.sippan.se.https egget.priv.lamest.se.54793: . ack 1 win 2170 (encap) 17:01:08.095189 (authentic,confidential): SPI 0xc31749f4: loller.sippan.se.https egget.priv.lamest.se.54793: . ack 1 win 2170 (encap) 17:01:10.459116 (authentic,confidential): SPI 0xc31749f4: loller.sippan.se.https egget.priv.lamest.se.54793: . ack 1 win 2170 (encap) So it appears that OpenBSD tries to send back traffic with ESP when it shouldn't. I'd also like to add that the exact same setup works with with isakmpd. Best regards Martin This is a known issue. The reason why it happens is not strictly documented. The change to the stack was introduced as part of the cleanup long time ago. Supposedly it's there to support TCP MD5 signatures, but I didn't verify that yet. There's this code in the
Re: iked responds with esp over external ips.
On 5 November 2014 13:28, Mike Belopuhov m...@belopuhov.com wrote: On 4 November 2014 17:06, Martin Larsson martin.larss...@gmail.com wrote: Hello! I've setup a tunnel between OpenBSD 5.6 using iked and an openwrt router running strongswan. The tunnel works great with ping and other traffic but traffic between the two external ip's dies. This is a site-to-site connection and nothing fancy. iked.conf on OpenBSD. ikev2 esp from $10.11.12.0/24 to $194.168.4.0/24 peer $tcgw srcid sippan.se # ipsecctl -sa FLOWS: flow esp in from 192.168.4.0/24 to 10.11.12.0/24 peer 82.17.12.21 srcid FQDN/sippan.se dstid FQDN/sswan.sippan.se type use flow esp out from 10.11.12.0/24 to 192.168.4.0/24 peer 82.17.12.21 srcid FQDN/sippan.se dstid FQDN/sswan.sippan.se type require flow esp out from ::/0 to ::/0 type deny SAD: esp tunnel from 82.17.12.21 to 130.51.23.4 spi 0x67483925 auth hmac-sha1 enc aes esp tunnel from 130.51.23.4 to 82.17.12.21 spi 0xcf1f39d1 auth hmac-sha1 enc aes # netstat -nr Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface default130.51.23.4 UGS 10 30430256 - 8 em0 10/8 link#5 UC 10 - 4 vether0 10.11.12.13fe:e1:ba:d0:d6:1c UHLl 01 - 1 lo0 10.255.255.255 link#5 UHLc 3 570 - 4 vether0 82.17.12.21 130.51.23.4 UGHD 0 30430251 - L 56 em0 127/8 127.0.0.1 UGRS 00 32768 8 lo0 127.0.0.1 127.0.0.1 UH 16 32768 4 lo0 194.48.213.128/27 link#1 UC 10 - 4 em0 130.51.23.4 00:00:cd:19:95:16 UHLc 20 - 4 em0 130.51.23.4 00:02:b3:aa:cc:c3 HLl00 - 1 lo0 224/4 127.0.0.1 URS00 32768 8 lo0 Internet6: -removed, dont use it- Encap: Source Port DestinationPort Proto SA(Address/Proto/Type/Direction) 192.168.4/24 0 10.11.12/240 0 82.17.12.21/esp/use/in 10.11.12/240 192.168.4/24 0 0 82.17.12.21/esp/require/out default0 default 0 0 none/esp/deny/out # tcpdump on openbsd while trying to connect with ssh to the external ip of the OpenBSD host from the exernal ip of the other end. # tcpdump host 82.17.12.21 tcpdump: listening on em0, link-type EN10MB tcpdump: WARNING: compensating for unaligned libpcap packets 16:49:55.539903 egget.priv.lamest.se.54158 loller.sippan.se.ssh: S 2729317717:2729317717(0) win 8192 mss 1460,nop,wscale 8,nop,nop,sackOK (DF) 16:49:55.539932 loller.sippan.se.ssh egget.priv.lamest.se.54158: S 2317435827:2317435827(0) ack 2729317718 win 16384 mss 1240,nop,nop,sackOK,nop,wscale 3 16:49:55.545936 egget.priv.lamest.se.54158 loller.sippan.se.ssh: . ack 1 win 256 (DF) 16:49:55.553927 esp loller.sippan.se egget.priv.lamest.se spi 0xcf1f39d1 seq 190 len 100 16:50:01.553883 esp loller.sippan.se egget.priv.lamest.se spi 0xcf1f39d1 seq 191 len 100 16:50:05.977468 esp egget.priv.lamest.se loller.sippan.se spi 0x67483925 seq 127 len 84 (DF) 16:50:05.977519 esp loller.sippan.se egget.priv.lamest.se spi 0xcf1f39d1 seq 192 len 84 There's another interesting behavior evident in this trace: first few (usually 1 or 2) packets (SYN-ACK from loller here) are not encrypted. That's because we update our PCB on input due to the presence of a matching SA in a very agile manner: first it doesn't really match, but we make sure next time it does (funny logic in the ipsp_spd_inp that coupled with the default IPsec policy).
Re: Multipath for HOST p2p routes
On 04/11/14(Tue) 13:10, Mike Belopuhov wrote:
On 4 November 2014 12:51, Martin Pieuchot mpieuc...@nolizard.org
wrote:
How are we suppose to support configuration with multiple p2p interfaces
pointing to the same destination address? Right now only one route to
host is added.
Diff below replaces a hack that move a host route from one p2p interface
to another by always installing MPATH routes. It assumes that multiples
p2p interfaces configured to the same destination address will have
different local addresses.
ok?
After discussing it with Martin it sounds like a good idea.
There's some semi-unrelated cleanup in in_ifinit that he has
promised to commit separately. OK mikeb for both changes.
Here's an updated diff, I just committed the loopback cleanup. Any
other comment or ok?
Index: in.c
===
RCS file: /cvs/src/sys/netinet/in.c,v
retrieving revision 1.107
diff -u -p -r1.107 in.c
--- in.c5 Nov 2014 14:40:51 - 1.107
+++ in.c5 Nov 2014 14:53:39 -
@@ -96,8 +96,8 @@ int in_lifaddr_ioctl(struct socket *, u_
void in_purgeaddr(struct ifaddr *);
int in_addprefix(struct in_ifaddr *);
int in_scrubprefix(struct in_ifaddr *);
-int in_addhost(struct in_ifaddr *);
-int in_scrubhost(struct in_ifaddr *);
+int in_addhost(struct in_ifaddr *, struct sockaddr_in *);
+int in_scrubhost(struct in_ifaddr *, struct sockaddr_in *);
int in_insert_prefix(struct in_ifaddr *);
void in_remove_prefix(struct in_ifaddr *);
@@ -313,11 +313,8 @@ in_control(struct socket *so, u_long cmd
splx(s);
return (error);
}
- if (ia-ia_flags IFA_ROUTE) {
- rt_ifa_del(ia-ia_ifa, RTF_HOST, sintosa(oldaddr));
- rt_ifa_add(ia-ia_ifa, RTF_UP | RTF_HOST,
- ia-ia_ifa.ifa_dstaddr);
- }
+ in_scrubhost(ia, oldaddr);
+ in_addhost(ia, ia-ia_dstaddr);
splx(s);
break;
@@ -597,7 +594,7 @@ void
in_ifscrub(struct ifnet *ifp, struct in_ifaddr *ia)
{
if (ISSET(ifp-if_flags, IFF_POINTOPOINT))
- in_scrubhost(ia);
+ in_scrubhost(ia, ia-ia_dstaddr);
else if (!ISSET(ifp-if_flags, IFF_LOOPBACK))
in_scrubprefix(ia);
}
@@ -657,22 +654,23 @@ in_ifinit(struct ifnet *ifp, struct in_i
* Add route for the network.
*/
ia-ia_ifa.ifa_metric = ifp-if_metric;
- if (ifp-if_flags IFF_BROADCAST) {
+ if (ISSET(ifp-if_flags, IFF_BROADCAST)) {
if (IN_RFC3021_SUBNET(ia-ia_netmask))
ia-ia_broadaddr.sin_addr.s_addr = 0;
else {
ia-ia_broadaddr.sin_addr.s_addr =
ia-ia_net | ~ia-ia_netmask;
}
- } else if (ifp-if_flags IFF_POINTOPOINT) {
- if (ia-ia_dstaddr.sin_family != AF_INET)
- goto out;
}
- if (ISSET(ifp-if_flags, IFF_POINTOPOINT))
- error = in_addhost(ia);
- else if (!ISSET(ifp-if_flags, IFF_LOOPBACK))
+ if (ISSET(ifp-if_flags, IFF_POINTOPOINT)) {
+ /* XXX We should not even call in_ifinit() in this case. */
+ if (ia-ia_dstaddr.sin_family != AF_INET)
+ goto out;
+ error = in_addhost(ia, ia-ia_dstaddr);
+ } else if (!ISSET(ifp-if_flags, IFF_LOOPBACK)) {
error = in_addprefix(ia);
+ }
/*
* If the interface supports multicast, join the all hosts
@@ -728,80 +726,15 @@ in_purgeaddr(struct ifaddr *ifa)
}
int
-in_addhost(struct in_ifaddr *ia0)
+in_addhost(struct in_ifaddr *ia, struct sockaddr_in *dst)
{
- struct in_ifaddr *ia;
- struct in_addr dst;
- int error;
-
- dst = ia0-ia_dstaddr.sin_addr;
-
- /*
-* If an interface already have a route to the same
-* destination don't do anything.
-*/
- TAILQ_FOREACH(ia, in_ifaddr, ia_list) {
- if (ia-ia_ifp-if_rdomain != ia0-ia_ifp-if_rdomain)
- continue;
-
- if (dst.s_addr != ia-ia_dstaddr.sin_addr.s_addr)
- continue;
-
- if ((ia-ia_flags IFA_ROUTE) == 0)
- continue;
-
- return (0);
- }
-
- error = rt_ifa_add(ia0-ia_ifa, RTF_UP | RTF_HOST,
- ia0-ia_ifa.ifa_dstaddr);
- if (!error)
- ia0-ia_flags |= IFA_ROUTE;
-
- return (error);
+ return rt_ifa_add(ia-ia_ifa, RTF_UP|RTF_HOST|RTF_MPATH,
sintosa(dst));
}
int
-in_scrubhost(struct in_ifaddr *ia0)
+in_scrubhost(struct in_ifaddr *ia, struct sockaddr_in *dst)
{
- struct in_ifaddr *ia;
- struct in_addr dst;
- int error;
-
- if ((ia0-ia_flags IFA_ROUTE) == 0)
- return (0);
-
- dst =
Re: EDNS0 and getrrsetbyname(3)
On Fri, Oct 31, 2014 at 03:03:11AM +0100, Mike Burns wrote: It is my understanding of the code that ssh(1) no longer supports DNSSEC. I say this because it calls getrrsetbyname(3) to check the secure flag, which calls into the ASR machine. In asr.c, the `pass0' function only parses two options, tcp and ndots:, ignoring edns0. Indeed, the asr_run(3) man page lists a lack of EDNS0 support as a caveat. Until EDNS0 is supported, it would be helpful to change the documentation. -Mike hi. some developers confirmed this, so i've fixed the docs. my change (below) is a bit different to yours though - for getrrset i just commented out the text. it seemed odd to explicitly say what it doesn;t do. and for resolv.conf i used a text already used by another option, and commented out some of the more verbose notes on edns0, to improve readability. hope that suits! and thanks for the mail, jmc Index: lib/libc/net/getrrsetbyname.3 === RCS file: /cvs/src/lib/libc/net/getrrsetbyname.3,v retrieving revision 1.19 retrieving revision 1.20 diff -u -r1.19 -r1.20 --- lib/libc/net/getrrsetbyname.3 23 Aug 2014 07:25:54 - 1.19 +++ lib/libc/net/getrrsetbyname.3 5 Nov 2014 15:12:23 - 1.20 @@ -1,4 +1,4 @@ -.\ $OpenBSD: getrrsetbyname.3,v 1.19 2014/08/23 07:25:54 jmc Exp $ +.\ $OpenBSD: getrrsetbyname.3,v 1.20 2014/11/05 15:12:23 jmc Exp $ .\ .\ Copyright (C) 2000, 2001 Internet Software Consortium. .\ @@ -15,7 +15,7 @@ .\ NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION .\ WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. .\ -.Dd $Mdocdate: August 23 2014 $ +.Dd $Mdocdate: November 5 2014 $ .Dt GETRRSETBYNAME 3 .Os .Sh NAME @@ -114,11 +114,11 @@ .Li struct rrsetinfo created by a call to .Fn getrrsetbyname . -.Pp -If the EDNS0 option is activated in -.Xr resolv.conf 5 , -.Fn getrrsetbyname -will request DNSSEC authentication using the EDNS0 DNSSEC OK (DO) bit. +.\ .Pp +.\ If the EDNS0 option is activated in +.\ .Xr resolv.conf 5 , +.\ .Fn getrrsetbyname +.\ will request DNSSEC authentication using the EDNS0 DNSSEC OK (DO) bit. .Sh RETURN VALUES .Fn getrrsetbyname returns zero on success, and one of the following error Index: share/man/man5/resolv.conf.5 === RCS file: /cvs/src/share/man/man5/resolv.conf.5,v retrieving revision 1.45 retrieving revision 1.46 diff -u -r1.45 -r1.46 --- share/man/man5/resolv.conf.523 Aug 2014 07:25:54 - 1.45 +++ share/man/man5/resolv.conf.55 Nov 2014 15:12:23 - 1.46 @@ -1,4 +1,4 @@ -.\$OpenBSD: resolv.conf.5,v 1.45 2014/08/23 07:25:54 jmc Exp $ +.\$OpenBSD: resolv.conf.5,v 1.46 2014/11/05 15:12:23 jmc Exp $ .\$NetBSD: resolv.conf.5,v 1.7 1996/03/06 18:22:16 scottr Exp $ .\ .\ Copyright (c) 1986, 1991 The Regents of the University of California. @@ -30,7 +30,7 @@ .\ .\ @(#)resolver.5 5.12 (Berkeley) 5/10/91 .\ -.Dd $Mdocdate: August 23 2014 $ +.Dd $Mdocdate: November 5 2014 $ .Dt RESOLV.CONF 5 .Os .Sh NAME @@ -266,21 +266,24 @@ so the option must be used only when all the servers listed in .Cm nameserver lines are able to handle the extension. -.Pp -To verify whether a server supports EDNS, -query it using the -.Xr dig 1 -query option -.Li +edns=0 : -the reply indicates compliance (EDNS version 0) -and whether a UDP packet larger than 512 bytes can be used. -Note that EDNS0 can cause the server to send packets -large enough to require fragmentation. -Other factors such as packet filters may impede these, -particularly if there is a reduced MTU, -as is often the case with -.Xr pppoe 4 -or with tunnels. +By default on +.Ox +this option does nothing. +.\ .Pp +.\ To verify whether a server supports EDNS, +.\ query it using the +.\ .Xr dig 1 +.\ query option +.\ .Li +edns=0 : +.\ the reply indicates compliance (EDNS version 0) +.\ and whether a UDP packet larger than 512 bytes can be used. +.\ Note that EDNS0 can cause the server to send packets +.\ large enough to require fragmentation. +.\ Other factors such as packet filters may impede these, +.\ particularly if there is a reduced MTU, +.\ as is often the case with +.\ .Xr pppoe 4 +.\ or with tunnels. .It Cm inet6 Enables support for IPv6-only applications, by setting RES_USE_INET6 in _res.options (see
rtentry leak
Diff below fixes a rtentry leak in rt_ifa_delloop() and do two other
conversions to rtfree(9). While here rename the pool in rtentry
which makes it easier to understand where to look for leaks.
I can commit these chunks separately if needed.
ok?
Index: net/route.c
===
RCS file: /home/ncvs/src/sys/net/route.c,v
retrieving revision 1.189
diff -u -p -r1.189 route.c
--- net/route.c 4 Nov 2014 15:24:40 - 1.189
+++ net/route.c 5 Nov 2014 15:26:45 -
@@ -215,7 +215,7 @@ route_init(void)
{
struct domain*dom;
- pool_init(rtentry_pool, sizeof(struct rtentry), 0, 0, 0, rtent,
+ pool_init(rtentry_pool, sizeof(struct rtentry), 0, 0, 0, rtentry,
NULL);
rn_init(); /* initialize all zeroes, all ones, mask table */
@@ -653,12 +653,12 @@ ifa_ifwithroute(int flags, struct sockad
struct rtentry *rt = rtalloc(gateway, 0, rtableid);
if (rt == NULL)
return (NULL);
- rt-rt_refcnt--;
/* The gateway must be local if the same address family. */
if ((rt-rt_flags RTF_GATEWAY)
rt_key(rt)-sa_family == dst-sa_family)
return (NULL);
ifa = rt-rt_ifa;
+ rtfree(rt);
if (ifa == NULL || ifa-ifa_ifp == NULL)
return (NULL);
}
@@ -1220,7 +1220,7 @@ rt_ifa_addloop(struct ifaddr *ifa)
if (rt == NULL || !ISSET(rt-rt_flags, flags));
rt_ifa_add(ifa, RTF_UP | flags, ifa-ifa_addr);
if (rt)
- rt-rt_refcnt--;
+ rtfree(rt);
}
/*
@@ -1267,7 +1267,7 @@ rt_ifa_delloop(struct ifaddr *ifa)
if (rt != NULL ISSET(rt-rt_flags, flags))
rt_ifa_del(ifa, flags, ifa-ifa_addr);
if (rt)
- rt-rt_refcnt--;
+ rtfree(rt);
}
/*
.ERROR target in makefile failed
Dear almighty tech,
For releasing taken resources like vnd device, for example :
# $OpenBSD: Makefile,v 1.2 2012/10/12 14:07:46 jsing Exp $
.PATH: ${.CURDIR}/../ramdiskB
BOOT=${DESTDIR}/usr/mdec/fdboot
RAMDISK=RAMDISK
NOBSDRD=1
.include ${.CURDIR}/../common/Makefile.inc
.ERROR:
echo HEO
-umount /mnt
-vnconfig -u vnd0
.END:
echo HH
.INTERRUPT:
echo INTERRUPT
LISTS+= ${.CURDIR}/list.local
I patched make to call an error target (Makefile.inc in common has the
correct rd_teardown this makefile is just for test) , and then realize
.END is not called not .INTERRUPT (putted here to check, i did not
send signal).
/usr/src/distrib/amd64/ramdiskB[OK] 10:23:16 -ksh
root@bsd56 # /usr/src/usr.bin/make/obj/make
dd if=/dev/zero of=/var/tmp/image.31550 bs=512 count=8960
*** Error 1 in /usr/src/distrib/amd64/ramdiskB
(../common/Makefile.inc:127 'do_files')
/usr/src/distrib/amd64/ramdiskB[1] 10:23:20 -ksh
root@bsd56 #
bug ? misused of target ?
Best regards, (follow the .ERROR patch)
Index: generate.c
===
RCS file: /cvs/src/usr.bin/make/generate.c,v
retrieving revision 1.16
diff -u -p -u -r1.16 generate.c
--- generate.c 18 May 2014 08:08:50 - 1.16
+++ generate.c 5 Nov 2014 15:14:35 -
@@ -115,6 +115,7 @@ char *table_nodes[] = {
M(NODE_WAIT),
M(NODE_BEGIN),
M(NODE_END),
+ M(NODE_ERROR),
M(NODE_INTERRUPT),
M(NODE_CHEAP),
M(NODE_EXPENSIVE),
Index: job.c
===
RCS file: /cvs/src/usr.bin/make/job.c,v
retrieving revision 1.135
diff -u -p -u -r1.135 job.c
--- job.c 14 Dec 2012 11:10:03 - 1.135
+++ job.c 5 Nov 2014 15:14:36 -
@@ -988,7 +988,8 @@ Job_Finish(void)
if ((end_node-type OP_DUMMY) == 0) {
if (problem) {
- Error(Errors reported so .END ignored);
+ Job_Make(error_node);
+ loop_handle_running_jobs();
} else {
Job_Make(end_node);
loop_handle_running_jobs();
Index: node_int.h
===
RCS file: /cvs/src/usr.bin/make/node_int.h,v
retrieving revision 1.4
diff -u -p -u -r1.4 node_int.h
--- node_int.h 9 Oct 2012 19:45:34 - 1.4
+++ node_int.h 5 Nov 2014 15:14:36 -
@@ -58,6 +58,7 @@
#define NODE_BEGIN .BEGIN
#define NODE_END .END
+#define NODE_ERROR .ERROR
#define NODE_INTERRUPT .INTERRUPT
#define NODE_CHEAP .CHEAP
#define NODE_EXPENSIVE .EXPENSIVE
Index: targ.c
===
RCS file: /cvs/src/usr.bin/make/targ.c,v
retrieving revision 1.75
diff -u -p -u -r1.75 targ.c
--- targ.c 12 May 2014 19:11:19 - 1.75
+++ targ.c 5 Nov 2014 15:14:36 -
@@ -125,7 +125,7 @@ struct ohash_info gnode_info = {
#define Targ_FindConstantNode(n, f) Targ_FindNodeh(n, sizeof(n), K_##n, f)
-GNode *begin_node, *end_node, *interrupt_node, *DEFAULT;
+GNode *begin_node, *end_node, *error_node, *interrupt_node, *DEFAULT;
void
Targ_Init(void)
@@ -136,6 +136,8 @@ Targ_Init(void)
begin_node-type |= OP_DUMMY | OP_NOTMAIN | OP_NODEFAULT;
end_node = Targ_FindConstantNode(NODE_END, TARG_CREATE);
end_node-type |= OP_DUMMY | OP_NOTMAIN | OP_NODEFAULT;
+ error_node = Targ_FindConstantNode(NODE_ERROR, TARG_CREATE);
+ error_node-type |= OP_DUMMY | OP_NOTMAIN | OP_NODEFAULT;
interrupt_node = Targ_FindConstantNode(NODE_INTERRUPT, TARG_CREATE);
interrupt_node-type |= OP_DUMMY | OP_NOTMAIN | OP_NODEFAULT;
DEFAULT = Targ_FindConstantNode(NODE_DEFAULT, TARG_CREATE);
Index: targ.h
===
RCS file: /cvs/src/usr.bin/make/targ.h,v
retrieving revision 1.13
diff -u -p -u -r1.13 targ.h
--- targ.h 23 Apr 2013 14:32:53 - 1.13
+++ targ.h 5 Nov 2014 15:14:36 -
@@ -65,7 +65,7 @@ extern void Targ_PrintCmd(void *);
extern void Targ_PrintType(int);
extern void Targ_PrintGraph(int);
-extern GNode *begin_node, *end_node, *interrupt_node, *DEFAULT;
+extern GNode *begin_node, *end_node, *error_node, *interrupt_node, *DEFAULT;
struct ohash_info;
extern struct ohash_info gnode_info;
--
-
() ascii ribbon campaign - against html e-mail
/\
Re: LibreSSL: GOST ciphers implementation
On Tue, Nov 04, 2014 at 08:42:03PM +, Miod Vallat wrote: Two weeks has passed. Is there anything that I can do to push GOST ciphers towards LibreSSL? Sorry about that. Joel and/or I need to review the diff again and push it. I'll try to find time for this next week-end (famous last words). Miod This is suspicious person for me (group of people?). There are lots of commits since about 2011 in many low-level and/or critical components from this person: linux kernel, android, gnupg, tcpdump, alsa, tor, openssl etc, etc.. I'm almost certainly wrong, but not too much there competencies for one person?
Re: LibreSSL: GOST ciphers implementation
This is suspicious person for me (group of people?). There are lots of commits since about 2011 in many low-level and/or critical components from this person: linux kernel, android, gnupg, tcpdump, alsa, tor, openssl etc, etc.. I'm almost certainly wrong, but not too much there competencies for one person? This kind of comment is an insult, both to the submitter, and to our code review process. That said, I remember Itojun used to have his name tied to way too many projects, not only because he was an amazing programmer, but also because he acted as the english spokeperson for many other japanese developers whose english skills weren't as good as Itojun's. This might be a similar story here, with russian people not good enough at english. Miod
Re: LibreSSL: GOST ciphers implementation
Hello, 2014-11-05 20:05 GMT+03:00 Артур Истомин art.is...@yandex.ru: On Tue, Nov 04, 2014 at 08:42:03PM +, Miod Vallat wrote: Two weeks has passed. Is there anything that I can do to push GOST ciphers towards LibreSSL? Sorry about that. Joel and/or I need to review the diff again and push it. I'll try to find time for this next week-end (famous last words). Miod This is suspicious person for me (group of people?). There are lots of commits since about 2011 in many low-level and/or critical components from this person: linux kernel, android, gnupg, tcpdump, alsa, tor, openssl etc, etc.. I'm almost certainly wrong, but not too much there competencies for one person? Thank you, I will take this as a compliment. Also you forgot few commits to OpenEmbedded/Angstrom/Yocto, QEmu, MPlayer, libgcrypt and maybe few other small projects. Hmm, this starts looking like a CV. Miod, no, I'm not an 'acting' or a 'proxy' man. All my contributions bear my name because I did them. -- With best wishes Dmitry
tetris(6): fix select() - poll() conversion
Pausing a tetris game currently causes a segfault due to a a null
pointer dereference.
Fix this by checking that s is non-NULL before accessing its members.
A number of comments and an error message still refer to select()
instead of poll(). Correct this as well.
Index: input.c
===
RCS file: /cvs/src/games/tetris/input.c,v
retrieving revision 1.13
diff -u -p -r1.13 input.c
--- input.c 3 Nov 2014 22:14:54 - 1.13
+++ input.c 5 Nov 2014 19:39:30 -
@@ -64,12 +64,12 @@
}
/*
- * Do a `read wait': select for reading from stdin, with timeout *tvp.
+ * Do a `read wait': poll for reading from stdin, with timeout *tvp.
* On return, modify *tvp to reflect the amount of time spent waiting.
* It will be positive only if input appeared before the time ran out;
* otherwise it will be zero or perhaps negative.
*
- * If tvp is nil, wait forever, but return if select is interrupted.
+ * If tvp is nil, wait forever, but return if poll is interrupted.
*
* Return 0 = no input, 1 = can read() from stdin
*/
@@ -90,14 +90,15 @@ rwait(struct timeval *tvp)
again:
pfd[0].fd = STDIN_FILENO;
pfd[0].events = POLLIN;
- switch (poll(pfd, 1, s-tv_sec * 1000 + s-tv_usec / 1000)) {
+ switch (poll(pfd, 1, s ? s-tv_sec * 1000 + s-tv_usec / 1000 :
+ INFTIM)) {
case -1:
if (tvp == 0)
return (-1);
if (errno == EINTR)
goto again;
- stop(select failed, help);
+ stop(poll failed, help);
/* NOTREACHED */
case 0: /* timed out */
@@ -115,7 +116,7 @@ again:
}
/*
- * `sleep' for the current turn time (using select).
+ * `sleep' for the current turn time (using poll).
* Eat any input that might be available.
*/
void
Re: LibreSSL: GOST ciphers implementation
On Wed, Nov 05, 2014 at 06:13:40PM +, Miod Vallat wrote: This is suspicious person for me (group of people?). There are lots of commits since about 2011 in many low-level and/or critical components from this person: linux kernel, android, gnupg, tcpdump, alsa, tor, openssl etc, etc.. I'm almost certainly wrong, but not too much there competencies for one person? This kind of comment is an insult, both to the submitter, and to our code review process. On the issue of the code review: http://cm.bell-labs.com/who/ken/trust.html (Ken Thompson, 1984) That said, I remember Itojun used to have his name tied to way too many projects, not only because he was an amazing programmer, but also because he acted as the english spokeperson for many other japanese developers whose english skills weren't as good as Itojun's. This might be a similar story here, with russian people not good enough at english. I said that 99.9% I'm wrong. But if I'm right, you guys will have a problem far worse than ever with ipsec. I believe that the code review of such diffs should be tightened when it comes to such important things as the kernel and/or the crypto. Tightened up to accepting of code only from people personally known to core developers. Otherwise OpenBSD's security little different from Linux security in today's reality. Eric S. Raymond's bazaar - The Achilles heel in a situation, where you can not say with certainty who came from diff.
Re: LibreSSL: GOST ciphers implementation
Артур Истомин said: I said that 99.9% I'm wrong. But if I'm right, you guys will have a problem far worse than ever with ipsec. I believe that the code review of such diffs should be tightened when it comes to such important things as the kernel and/or the crypto. Tightened up to accepting of code only from people personally known to core developers. Otherwise OpenBSD's security little different from Linux security in today's reality. Eric S. Raymond's bazaar - The Achilles heel in a situation, where you can not say with certainty who came from diff. Yes, educate them more! Sure their knowledge of code review, kernels and security is far inferior to yours. -- Dmitrij D. Czarkoff
Re: LibreSSL: GOST ciphers implementation
On Wed, Nov 05, 2014 at 06:13:40PM +, Miod Vallat wrote: This is suspicious person for me (group of people?). There are lots of commits since about 2011 in many low-level and/or critical components from this person: linux kernel, android, gnupg, tcpdump, alsa, tor, openssl etc, etc.. I'm almost certainly wrong, but not too much there competencies for one person? This kind of comment is an insult, both to the submitter, and to our code review process. On the issue of the code review: http://cm.bell-labs.com/who/ken/trust.html (Ken Thompson, 1984) And... do you trust me? Do you trust Miod? Why? No really, precisely why do you trust us? What a joke. That said, I remember Itojun used to have his name tied to way too many projects, not only because he was an amazing programmer, but also because he acted as the english spokeperson for many other japanese developers whose english skills weren't as good as Itojun's. This might be a similar story here, with russian people not good enough at english. I said that 99.9% I'm wrong. But if I'm right, you guys will have a problem far worse than ever with ipsec. I believe that the code review of such diffs should be tightened when it comes to such important things as the kernel and/or the crypto. Tightened up to accepting of code only from people personally known to core developers. That is quite a fiction. How do we find people on the internet who care, and knit them into a community, and then somewhere down the road meet them and have them become this so-called 'core developer' group? We start reading code from them. Perhaps it is easier for people who are not part of this process, to find ways to disparage this human effort. Otherwise OpenBSD's security little different from Linux security in today's reality. Eric S. Raymond's bazaar - The Achilles heel in a situation, where you can not say with certainty who came from diff. Well, we never promised our processes to be better than the standard human processes. But I guess you believe we can do better, without any significant backing. So who's the fool now? I think you are.
Re: LibreSSL: GOST ciphers implementation
On 5 Nov 2014, at 20:25, Theo de Raadt wrote: How do we find people on the internet who care, and knit them into a community, and then somewhere down the road meet them and have them become this so-called 'core developer' group? We start reading code from them. The code, yes, the code. Nothing to stop anyone from being suspicious for any reason whatsoever and giving some code some extra review. So much the better. devin -- contact info: http://nacredata.com/devin gpg public key: http://www.nacredata.com/public_key.txt Use unique, strong passwords! https://www.nacredata.com/password.php
Re: LibreSSL: GOST ciphers implementation
On 5 Nov 2014, at 20:25, Theo de Raadt wrote: How do we find people on the internet who care, and knit them into a community, and then somewhere down the road meet them and have them become this so-called 'core developer' group? We start reading code from them. The code, yes, the code. Nothing to stop anyone from being suspicious for any reason whatsoever and giving some code some extra review. So much the better. Yes, so much the better, but in all circumstances, no matter what. There is nothing stopping Mr. Istom from suspending his suspicions -- oh let's call them accusations for that is what they are -- and reading the code, performing that review as well. Never expect a group to perform a task which an individual won't.
Re: tetris(6): fix select() - poll() conversion
On Wed, Nov 05, 2014 at 08:45:07PM +0100, Theo Buehler wrote:
Pausing a tetris game currently causes a segfault due to a a null
pointer dereference.
Fix this by checking that s is non-NULL before accessing its members.
A number of comments and an error message still refer to select()
instead of poll(). Correct this as well.
Index: input.c
===
RCS file: /cvs/src/games/tetris/input.c,v
retrieving revision 1.13
diff -u -p -r1.13 input.c
--- input.c 3 Nov 2014 22:14:54 - 1.13
+++ input.c 5 Nov 2014 19:39:30 -
@@ -64,12 +64,12 @@
}
/*
- * Do a `read wait': select for reading from stdin, with timeout *tvp.
+ * Do a `read wait': poll for reading from stdin, with timeout *tvp.
* On return, modify *tvp to reflect the amount of time spent waiting.
* It will be positive only if input appeared before the time ran out;
* otherwise it will be zero or perhaps negative.
*
- * If tvp is nil, wait forever, but return if select is interrupted.
+ * If tvp is nil, wait forever, but return if poll is interrupted.
*
* Return 0 = no input, 1 = can read() from stdin
*/
@@ -90,14 +90,15 @@ rwait(struct timeval *tvp)
again:
pfd[0].fd = STDIN_FILENO;
pfd[0].events = POLLIN;
- switch (poll(pfd, 1, s-tv_sec * 1000 + s-tv_usec / 1000)) {
+ switch (poll(pfd, 1, s ? s-tv_sec * 1000 + s-tv_usec / 1000 :
I propose getting rid of the s pointer all together as such:
Index: input.c
===
RCS file: /cvs/obsd/src/games/tetris/input.c,v
retrieving revision 1.13
diff -u -p -u -p -r1.13 input.c
--- input.c 3 Nov 2014 22:14:54 - 1.13
+++ input.c 5 Nov 2014 22:40:47 -
@@ -64,19 +64,20 @@
}
/*
- * Do a `read wait': select for reading from stdin, with timeout *tvp.
+ * Do a `read wait': poll for reading from stdin, with timeout *tvp.
* On return, modify *tvp to reflect the amount of time spent waiting.
* It will be positive only if input appeared before the time ran out;
* otherwise it will be zero or perhaps negative.
*
- * If tvp is nil, wait forever, but return if select is interrupted.
+ * If tvp is nil, wait forever, but return if poll is interrupted.
*
* Return 0 = no input, 1 = can read() from stdin
*/
int
rwait(struct timeval *tvp)
{
- struct timeval starttv, endtv, *s;
+ int timo = INFTIM;
+ struct timeval starttv, endtv;
struct pollfd pfd[1];
#defineNILTZ ((struct timezone *)0)
@@ -84,20 +85,19 @@ rwait(struct timeval *tvp)
if (tvp) {
(void) gettimeofday(starttv, NILTZ);
endtv = *tvp;
- s = endtv;
- } else
- s = NULL;
+ timo = endtv.tv_sec * 1000 + endtv.tv_usec / 1000;
+ }
again:
pfd[0].fd = STDIN_FILENO;
pfd[0].events = POLLIN;
- switch (poll(pfd, 1, s-tv_sec * 1000 + s-tv_usec / 1000)) {
+ switch (poll(pfd, 1, timo)) {
case -1:
if (tvp == 0)
return (-1);
if (errno == EINTR)
goto again;
- stop(select failed, help);
+ stop(poll failed, help);
/* NOTREACHED */
case 0: /* timed out */
@@ -115,7 +115,7 @@ again:
}
/*
- * `sleep' for the current turn time (using select).
+ * `sleep' for the current turn time (using poll).
* Eat any input that might be available.
*/
void
--patrick
+ INFTIM)) {
case -1:
if (tvp == 0)
return (-1);
if (errno == EINTR)
goto again;
- stop(select failed, help);
+ stop(poll failed, help);
/* NOTREACHED */
case 0: /* timed out */
@@ -115,7 +116,7 @@ again:
}
/*
- * `sleep' for the current turn time (using select).
+ * `sleep' for the current turn time (using poll).
* Eat any input that might be available.
*/
void
Re: LibreSSL: GOST ciphers implementation
On Wed, Nov 05, 2014 at 01:25:32PM -0700, Theo de Raadt wrote: On Wed, Nov 05, 2014 at 06:13:40PM +, Miod Vallat wrote: This is suspicious person for me (group of people?). There are lots of commits since about 2011 in many low-level and/or critical components from this person: linux kernel, android, gnupg, tcpdump, alsa, tor, openssl etc, etc.. I'm almost certainly wrong, but not too much there competencies for one person? This kind of comment is an insult, both to the submitter, and to our code review process. On the issue of the code review: http://cm.bell-labs.com/who/ken/trust.html (Ken Thompson, 1984) And... do you trust me? Do you trust Miod? Why? No really, precisely why do you trust us? What a joke. That said, I remember Itojun used to have his name tied to way too many projects, not only because he was an amazing programmer, but also because he acted as the english spokeperson for many other japanese developers whose english skills weren't as good as Itojun's. This might be a similar story here, with russian people not good enough at english. I said that 99.9% I'm wrong. But if I'm right, you guys will have a problem far worse than ever with ipsec. I believe that the code review of such diffs should be tightened when it comes to such important things as the kernel and/or the crypto. Tightened up to accepting of code only from people personally known to core developers. That is quite a fiction. How do we find people on the internet who care, and knit them into a community, and then somewhere down the road meet them and have them become this so-called 'core developer' group? We start reading code from them. Perhaps it is easier for people who are not part of this process, to find ways to disparage this human effort. Otherwise OpenBSD's security little different from Linux security in today's reality. Eric S. Raymond's bazaar - The Achilles heel in a situation, where you can not say with certainty who came from diff. Well, we never promised our processes to be better than the standard human processes. But I guess you believe we can do better, without any significant backing. So who's the fool now? I think you are. So, in fact, all that you said: we address and solve technical problems only. But this is the real world, not all problems can be solved in it by code. It was not accusation to Dmitry, like you said in another e-mail. I'm just trying to point out the problem, which seems to me important. I perfectly see the folly of my proposal. But it was a proposal, attempt to begin discussion of the problem. But based on your answer, you do not see the problem. You can not see the forest for the trees. You think, that all security problems are technical problems, that can be solved with the help of the compiler. But with such mindset, at current trends, in 5-7 years the only code that you can trust in the project, it will only your own code.
Re: LibreSSL: GOST ciphers implementation
On 05.11.2014 23:03, Артур Истомин wrote: It was not accusation to Dmitry, like you said in another e-mail. I'm just trying to point out the problem, which seems to me important. what problem?? I don't get what your problem is. There is a guy asking for a code review and Miod said that he didn't get to it yet. So the code will be reviewed and checked by at least 4 eyes at some point - like most things going into OpenBSD. So, you are saying because this guy writes a lot of code he can not be trusted? It is unhuman to write that much code? WTH? Why do you trust Theo or Ted or Bob? Have you actually reviewed the code this person produces and found strange things or discovered secret plans to take over the world? If so, please point them out. Maybe Theo an the others can learn from you and become unnaturally good at this as well. Otherwise It is very obvious that you have an agenda here (copyrighted by Theo :-)) I wish you luck writing your own OS as in 5 years you don't trust any other code besides your own (your words). *kopfschüttel* Lars
Re: LibreSSL: GOST ciphers implementation
?? ?? [art.is...@yandex.ru] wrote: On Tue, Nov 04, 2014 at 08:42:03PM +, Miod Vallat wrote: Two weeks has passed. Is there anything that I can do to push GOST ciphers towards LibreSSL? Sorry about that. Joel and/or I need to review the diff again and push it. I'll try to find time for this next week-end (famous last words). Miod This is suspicious person for me (group of people?). There are lots of commits since about 2011 in many low-level and/or critical components from this person: linux kernel, android, gnupg, tcpdump, alsa, tor, openssl etc, etc.. I'm almost certainly wrong, but not too much there competencies for one person? So, you're saying, he's really dmi...@svr.gov.ru, the source of Russian backdoors into technology worldwide!!! I guess the open-source ecosystem has been thoroughly poisoned! Putin is going to take us over. OpenBSD and Linux are ruined! Fuck, I'm switching to Windows 8.
libtls future
Looking over libtls it struck me that this is the best-designed TLS API I've ever seen, so it was a bit disheartening to look at the code and find that it was mainly just wrapping libssl and abstracting away its fragile, haphazard design choices. Though even just this is obviously already an unconditional good, are there plans for enough of libssl to be split off, cleaned up, and rolled directly into libtls so that the libtls - libssl dependency can be broken for good?
Re: libtls future
Looking over libtls it struck me that this is the best-designed TLS API I've ever seen, so it was a bit disheartening to look at the code and find that it was mainly just wrapping libssl and abstracting away its fragile, haphazard design choices. Though even just this is obviously already an unconditional good, are there plans for enough of libssl to be split off, cleaned up, and rolled directly into libtls so that the libtls - libssl dependency can be broken for good? How is your attempt at doing this going?
Re: LibreSSL: GOST ciphers implementation
I perfectly see the folly of my proposal. But it was a proposal, attempt to begin discussion of the problem. But based on your answer, you do not see the problem. You can not see the forest for the trees. You think, that all security problems are technical problems, that can be solved with the help of the compiler. No, the primary difference is that we act. Whereas you just talk (and accuse). But with such mindset, at current trends, in 5-7 years the only code that you can trust in the project, it will only your own code. In 5-7 years, concrete in bridges is decaying, traffic light standards are decaying. Slowly, as it does. That fact does mean engineers shouldn't keep designing bridges and traffic intersections. We never said our code should be trusted. In this group, we only try to build robust design practices that other systems could (should?) copy to make their systems more robust. We also don't promise to be working on everything revelant, either.
go back to sleep if lid closed when resuming
Formerly Prevent Hot Backpack diff. This puts the machine back to
sleep (or hibernate, if that's where you came from) if the lid is
still closed on resume. Stops the machine from staying awake if the
lid flexes or slightly opens while in your bag, triggering an
unwanted wake event. Note - the machine will wake, then go back to
sleep using this diff. So it will take a few seconds (or longer
when using ZZZ).
There are some unhandled cases:
1. softraid crypto hibernate - this diff won't work in that scenario
as the machine will be sitting at the passphrase prompt.
2. machines with lids closed in docks, that are awakened by pressing
the power button instead of opening the lid.
Testers welcome.
-ml
Index: dev/acpi/acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.272
diff -u -p -a -u -r1.272 acpi.c
--- dev/acpi/acpi.c 26 Sep 2014 09:25:38 - 1.272
+++ dev/acpi/acpi.c 12 Oct 2014 18:46:42 -
@@ -2252,6 +2252,12 @@ fail_alloc:
acpi_record_event(sc, APM_NORMAL_RESUME);
acpi_indicator(sc, ACPI_SST_WORKING);
+ /*
+* If we woke up but the lid is closed, go back to sleep
+*/
+ if (!acpibtn_checklidopen())
+ acpi_addtask(sc, acpi_sleep_task, sc, state);
+
fail_tts:
return (error);
}
Index: dev/acpi/acpibtn.c
===
RCS file: /cvs/src/sys/dev/acpi/acpibtn.c,v
retrieving revision 1.37
diff -u -p -a -u -r1.37 acpibtn.c
--- dev/acpi/acpibtn.c 16 Oct 2014 17:46:06 - 1.37
+++ dev/acpi/acpibtn.c 6 Nov 2014 03:01:01 -
@@ -76,6 +76,25 @@ struct cfdriver acpibtn_cd = {
const char *acpibtn_hids[] = { ACPI_DEV_LD, ACPI_DEV_PBD, ACPI_DEV_SBD, 0 };
int
+acpibtn_checklidopen(void)
+{
+ int64_t val, status;
+ struct acpi_lid *lid;
+
+ status = 0;
+
+ /* Check if any of the lid(s) are open */
+ SLIST_FOREACH(lid, acpibtn_lids, abl_link)
+ if (!aml_evalinteger(lid-abl_softc-sc_acpi,
+ lid-abl_softc-sc_devnode, _LID, 0, NULL, val))
+ status |= val;
+ else
+ return (0);
+
+ return (status);
+}
+
+int
acpibtn_setpsw(struct acpibtn_softc *sc, int psw)
{
struct aml_valueval;
Index: dev/acpi/acpidev.h
===
RCS file: /cvs/src/sys/dev/acpi/acpidev.h,v
retrieving revision 1.34
diff -u -p -a -u -r1.34 acpidev.h
--- dev/acpi/acpidev.h 23 May 2014 19:17:39 - 1.34
+++ dev/acpi/acpidev.h 12 Oct 2014 18:47:22 -
@@ -337,4 +337,5 @@ struct acpiec_softc {
void acpibtn_disable_psw(void);
void acpibtn_enable_psw(void);
+intacpibtn_checklidopen(void);
#endif /* __DEV_ACPI_ACPIDEV_H__ */
Re: rtentry leak
Martin Pieuchot [mpieuc...@nolizard.org] wrote:
@@ -653,12 +653,12 @@ ifa_ifwithroute(int flags, struct sockad
struct rtentry *rt = rtalloc(gateway, 0, rtableid);
if (rt == NULL)
return (NULL);
- rt-rt_refcnt--;
/* The gateway must be local if the same address family. */
if ((rt-rt_flags RTF_GATEWAY)
rt_key(rt)-sa_family == dst-sa_family)
return (NULL);
And
if ((rt-rt_flags RTF_GATEWAY)
rt_key(rt)-sa_family == dst-sa_family) {
+ rtfree(rt);
return (NULL);
}
ifa = rt-rt_ifa;
+ rtfree(rt);
if (ifa == NULL || ifa-ifa_ifp == NULL)
return (NULL);
Re: need help setting an encrypted root FS on dual boot system
Matthieu Herrb [matth...@herrb.eu] wrote: Hi, I've a laptop with Ubuntu 14.04/OpenBSD-current dual boot. I'm trying to convert the OpenBSD FS to softraid(4) encryption with passphrase. I'm booting from an USB drive to access the disk to shuffle data on it. After backing up my data, changing the OpenBSD disklabel in sd0 to have one RAID partition and one swap partition, running bioctl to setup an encrypted sd2 softraid and restoring my data, I'm stuck with bootblocks. What is the correct installboot incantation to setup bootblocks so that Ubuuntu's grub which chainloads the OpenBSD part of the disk loads a softraid-aware biosboot ? Doesn't installboot load the first-stage at the beginning of the OpenBSD partition according to disklabel? Grub is just replacing the MBR. I don't understand how crypto would make grub-first-stage step any different. (for that matter, I also don't understand how the first-stage can even load the second-stage /boot from an encrypted partition!!)
Re: libtls future
On Thu, 6 Nov 2014, Daniel wrote: Looking over libtls it struck me that this is the best-designed TLS API I've ever seen, so it was a bit disheartening to look at the code and find that it was mainly just wrapping libssl and abstracting away its fragile, haphazard design choices. Though even just this is obviously already an unconditional good, are there plans for enough of libssl to be split off, cleaned up, and rolled directly into libtls so that the libtls - libssl dependency can be broken for good? The short answer is yes, that's the long term ideal. The longer answer is that there is still a huge amount of software that uses libssl and even if we took the time to write a brand new TLS implementation, it would be of little benefit until everything started using it. The amount of effort required to implement a new TLS from scratch is significant. Same goes with porting existing software to use it. For the time being we're far better off investing time into fixing libssl as much as we possibly can (while being held to its existing API), while also providing a new TLS API that things can start using now. Hopefully we'll eventually get to the point where libtls stands on its own... -- Action without study is fatal. Study without action is futile. -- Mary Ritter Beard
