Re: Typo in macro name for ASN
On 2014/06/08 22:49, Loganaden Velvindron wrote:
On Fri, Jun 06, 2014 at 09:47:03AM +0200, Miod Vallat wrote:
From Quanah Gibson-Mount:
UNKOWN-UNKNOWN
Index: crypto/asn1/asn1_err.c
Please refrain from sending diffs you obviously didn't test.
Miod
Compiled and tested:
$ ag ASN1_R_UNK.*FORM
src/crypto/asn1/a_mbstr.c
145:ASN1err(ASN1_F_ASN1_MBSTRING_NCOPY, ASN1_R_UNKNOWN_FORMAT);
src/crypto/asn1/asn1_err.c
300:{ERR_REASON(ASN1_R_UNKNOWN_FORMAT) , unknown format},
306:{ERR_REASON(ASN1_R_UNKOWN_FORMAT), unknown format},
src/crypto/asn1/asn1.h
1335:#define ASN1_R_UNKNOWN_FORMAT 160
1341:#define ASN1_R_UNKOWN_FORMAT195
src/crypto/asn1/asn1_gen.c
358:ASN1err(ASN1_F_ASN1_CB, ASN1_R_UNKOWN_FORMAT);
mirrorlist file proposal
OpenBSD has one of the simplest and most compact installers out there. However, at the end of the installation you need to have another internet connected OS in order to copy the address of the mirror you wish to use for package management to your freshly installed OpenBSD. Why not include a mirrorlist file in /etc (or wherever) which the user will edit and simply include in his .profile (using source /etc/mirrorlist)? Sample mirrorlist for the amd64 architecture compiled from the mirrors at the OpenBSD website: ## ## OpenBSD mirrorlist ## Uncomment only *one* server (http or ftp) ## ## ## HTTP MIRROR LIST: ## ##Australia (Adelaide) #PKG_PATH=http://mirror.internode.on.net/pub/OpenBSD/5.5/packages/amd64/ ##Australia (Brisbane) #PKG_PATH=http://mirror.aarnet.edu.au/pub/OpenBSD/5.5/packages/amd64/ ##Australia (Perth) #PKG_PATH=http://ftp.iinet.net.au/pub/OpenBSD/5.5/packages/amd64/ ##Austria (Vienna) #PKG_PATH=http://ftp5.eu.openbsd.org/ftp/pub/OpenBSD/5.5/packages/amd64/ ##Austria (Vienna) #PKG_PATH=http://ftp2.eu.openbsd.org/pub/OpenBSD/5.5/packages/amd64/ ##Belgium (Brussels) #PKG_PATH=http://ftp.belnet.be/pub/OpenBSD/5.5/packages/amd64/ ##Brazil (Sao Paulo) #PKG_PATH=http://openbsd.locaweb.com.br/pub/OpenBSD/5.5/packages/amd64/ ##Bulgaria (Sofia) #PKG_PATH=http://mirror.telepoint.bg/OpenBSD/5.5/packages/amd64/ ##Canada (Alberta) #PKG_PATH=http://ftp.OpenBSD.org/pub/OpenBSD/5.5/packages/amd64/ ##Canada (Kingston, ON) #PKG_PATH=http://athena.caslab.queensu.ca/pub/OpenBSD/5.5/packages/amd64/ ##Canada (Toronto, ON) #PKG_PATH=http://openbsd.cs.toronto.edu/pub/OpenBSD/5.5/packages/amd64/ ##Costa Rica #PKG_PATH=http://mirrors.ucr.ac.cr/OpenBSD/5.5/packages/amd64/ ##Czech Republic #PKG_PATH=http://mirror.steadynet.cz/pub/OpenBSD/5.5/packages/amd64/ ##Denmark (Aalborg) #PKG_PATH=http://ftp.openbsd.dk/pub/OpenBSD/5.5/packages/amd64/ ##Estonia (Tallinn) #PKG_PATH=http://ftp.aso.ee/pub/OpenBSD/5.5/packages/amd64/ ##Estonia (Tallinn) #PKG_PATH=http://ftp.estpak.ee/pub/OpenBSD/5.5/packages/amd64/ ##France (Paris) #PKG_PATH=http://ftp.fr.openbsd.org/pub/OpenBSD/5.5/packages/amd64/ ##France (Paris) #PKG_PATH=http://ftp2.fr.openbsd.org/pub/OpenBSD/5.5/packages/amd64/ ##France (Paris) #PKG_PATH=http://mirrors.ircam.fr/pub/OpenBSD/5.5/packages/amd64/ ##Germany (Erlangen) #PKG_PATH=http://openbsd.cs.fau.de/pub/OpenBSD/5.5/packages/amd64/ ##Germany (Berlin) #PKG_PATH=http://ftp.spline.de/pub/OpenBSD/5.5/packages/amd64/ ##Germany (Oldenburg) #PKG_PATH=http://ftp.bytemine.net/pub/OpenBSD/5.5/packages/amd64/ ##Germany (Aachen) #PKG_PATH=http://ftp.halifax.rwth-aachen.de/OpenBSD/5.5/packages/amd64/ ##Germany (Hamburg) #PKG_PATH=http://artfiles.org/OpenBSD/5.5/packages/amd64/ ##Germany (Frankfurt) #PKG_PATH=http://ftp.hostserver.de/pub/OpenBSD/5.5/packages/amd64/ ##Greece (Heraklion) #PKG_PATH=http://ftp.cc.uoc.gr/mirrors/OpenBSD/5.5/packages/amd64/ ##Hungary (Budapest) #PKG_PATH=http://ftp.fsn.hu/pub/OpenBSD/5.5/packages/amd64/ ##Indonesia (Surabaya, Java) #PKG_PATH=http://kartolo.sby.datautama.net.id/pub/OpenBSD/5.5/packages/amd64/ ##Ireland (Dublin) #PKG_PATH=http://ftp.heanet.ie/pub/OpenBSD/5.5/packages/amd64/ ##Italy (Rome) #PKG_PATH=http://openbsd.mirror.garr.it/pub/OpenBSD/5.5/packages/amd64/ ##Japan (Ishikawa) #PKG_PATH=http://ftp.jaist.ac.jp/pub/OpenBSD/5.5/packages/amd64/ ##Japan (Saitama) #PKG_PATH=http://www.ftp.ne.jp/OpenBSD/5.5/packages/amd64/ ##The Netherlands (Utrecht) #PKG_PATH=http://ftp.nluug.nl/pub/OpenBSD/5.5/packages/amd64/ ##The Netherlands (Ede) #PKG_PATH=http://ftp.bit.nl/pub/OpenBSD/5.5/packages/amd64/ ##Pakistan (Karachi) #PKG_PATH=http://stingray.cyber.net.pk/pub/OpenBSD/5.5/packages/amd64/ ##Poland (Oswiecim) #PKG_PATH=http://piotrkosoft.net/pub/OpenBSD/5.5/packages/amd64/ ##Poland (Warszawa) #PKG_PATH=http://ftp.icm.edu.pl/pub/OpenBSD/5.5/packages/amd64/ ##Russia (Moscow) #PKG_PATH=http://mirror.yandex.ru/pub/OpenBSD/5.5/packages/amd64/ ##Saudi Arabia (Riyadh) #PKG_PATH=http://mirrors.isu.net.sa/pub/ftp.openbsd.org/ ##Slovenia (Ljubljana) #PKG_PATH=http://www.obsd.si/pub/OpenBSD/5.5/packages/amd64/ ##South Africa (Johannesburg) #PKG_PATH=http://mirror.is.co.za/mirror/ftp.openbsd.org/ ##Spain (Oviedo) #PKG_PATH=http://mirror.codigo23.net/pub/OpenBSD/5.5/packages/amd64/ ##Sweden (Stockholm) #PKG_PATH=http://ftp.eu.openbsd.org/pub/OpenBSD/5.5/packages/amd64/ ##Switzerland (Zurich) #PKG_PATH=http://mirror.switch.ch/ftp/pub/OpenBSD/5.5/packages/amd64/ ##Switzerland (Zurich) #PKG_PATH=http://ftp.ch.openbsd.org/pub/OpenBSD/5.5/packages/amd64/ ##United Kingdom (Kent) #PKG_PATH=http://www.mirrorservice.org/pub/OpenBSD/5.5/packages/amd64/ ##United Kingdom (Manchester) #PKG_PATH=http://mirror.bytemark.co.uk/OpenBSD/5.5/packages/amd64/
Re: [PATCH 9] installboot: malloc/memset = calloc
Commited. Thanks. On Sun, 1 Jun 2014, Benjamin Baier wrote: On Sun, 1 Jun 2014 00:57:43 +1000 Joel Sing j...@sing.id.au wrote: In this case I think readability wins. I do not believe that there is a lot to gain from overflow protection given the numbers used in these calculations are very small (and many are already bounds checked in some form or other). Well, I had to ask. Here is option 2. Index: bootstrap.c === RCS file: /cvs/src/usr.sbin/installboot/bootstrap.c,v retrieving revision 1.3 diff -u -p -r1.3 bootstrap.c --- bootstrap.c 28 Dec 2013 12:01:33 - 1.3 +++ bootstrap.c 31 May 2014 18:14:56 - @@ -68,10 +68,9 @@ bootstrap(int devfd, char *dev, char *bo fprintf(stderr, bootstrap is %zu bytes (%zu sectors @ %u bytes = %zu bytes)\n, (ssize_t)sb.st_size, bootsec, dl.d_secsize, bootsize); - boot = malloc(bootsize); + boot = calloc(1, bootsize); if (boot == NULL) - err(1, malloc); - memset(boot, 0, bootsize); + err(1, calloc); if (read(fd, boot, bootsize) != (ssize_t)sb.st_size) err(1, read); close(fd); Index: i386_softraid.c === RCS file: /cvs/src/usr.sbin/installboot/i386_softraid.c,v retrieving revision 1.1 diff -u -p -r1.1 i386_softraid.c --- i386_softraid.c 19 Jan 2014 02:58:50 - 1.1 +++ i386_softraid.c 31 May 2014 18:14:56 - @@ -129,11 +129,10 @@ sr_install_bootldr(int devfd, char *dev) inodeblk = nblocks - 1; bootsize = nblocks * SR_FS_BLOCKSIZE; - p = malloc(bootsize); + p = calloc(1, bootsize); if (p == NULL) err(1, NULL); - memset(p, 0, bootsize); fd = open(stage2, O_RDONLY, 0); if (fd == -1) err(1, NULL); Index: sparc64_installboot.c === RCS file: /cvs/src/usr.sbin/installboot/sparc64_installboot.c,v retrieving revision 1.1 diff -u -p -r1.1 sparc64_installboot.c --- sparc64_installboot.c 19 Jan 2014 02:58:50 - 1.1 +++ sparc64_installboot.c 31 May 2014 18:14:56 - @@ -68,10 +68,9 @@ md_loadboot(void) if (blksize SBSIZE - DEV_BSIZE) errx(1, boot blocks too big (%zu %d), blksize, SBSIZE - DEV_BSIZE); - blkstore = malloc(blksize); + blkstore = calloc(1, blksize); if (blkstore == NULL) - err(1, malloc); - memset(blkstore, 0, blksize); + err(1, calloc); if (read(fd, blkstore, sb.st_size) != (ssize_t)sb.st_size) err(1, read); close(fd); -- Action without study is fatal. Study without action is futile. -- Mary Ritter Beard
Re: mirrorlist file proposal
Eww... See distrib/notes/mirrors and installpath from pkg.conf(5).
ifstated(8) improvement
Hi tech, I've been using ifstated for years now for failover my links and I've developed quite some tools on top of it. But, I've recently reached a cornerstone. I've developed a series of scripts that are called with the run argument on the init of each state that perform a series of tasks. One of these tasks is to write to a database (currently sqlite) and based on the last state changes, perform different actions. But, since I can't talk directly to the ifstated daemon, I have a delay since I can affect any state change on it. So, I've been planning on improving ifstated itself, for it to be able to keep track of state changes and the time they happened, so it can be able to improve it's decision making capabilities in the sense that it can perform state changes based on previous states changes. Not just on external commands results or interface statuses. You could say something like this: set-state X if ! previous_state Y More to that, it could be also based on a more simplistic approach, using counters. With the possibility of zeroing the counters from ifstated.conf based on conditions. Or both, time and counters. So one could change to a different state if one of the links is flapping between states. I know this makes it not a pure machine state, but I believe that the improvements can be worth the change. What you guys think? Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: ifstated(8) improvement
On Mon, Jun 9, 2014 at 10:38 AM, Giancarlo Razzolini
grazzol...@gmail.com wrote:
Hi tech,
I've been using ifstated for years now for failover my links and
I've developed quite some tools on top of it. But, I've recently reached
a cornerstone. I've developed a series of scripts that are called with
the run argument on the init of each state that perform a series of
tasks. One of these tasks is to write to a database (currently sqlite)
and based on the last state changes, perform different actions. But,
since I can't talk directly to the ifstated daemon, I have a delay since
I can affect any state change on it.
So, I've been planning on improving ifstated itself, for it to be
able to keep track of state changes and the time they happened, so it
can be able to improve it's decision making capabilities in the sense
that it can perform state changes based on previous states changes. Not
just on external commands results or interface statuses. You could say
something like this:
set-state X
if ! previous_state Y
More to that, it could be also based on a more simplistic approach,
using counters. With the possibility of zeroing the counters from
ifstated.conf based on conditions. Or both, time and counters. So one
could change to a different state if one of the links is flapping
between states. I know this makes it not a pure machine state, but I
believe that the improvements can be worth the change. What you guys think?
Cheers,
--
Giancarlo Razzolini
GPG: 4096R/77B981BC
ifstated is a cool FSM emgine for handling the carp problems,
for more complex need , instead of hacking this not complete FSM engine,
i would just used another software.
The last time, i just use plain perl script, because it was convenient
and easy to read,
using a true FSM design was just making the logic more complex.
IMHO the way to improve ifstated is to fork it so it becomes a full FSM engine,
with transition and node definition, and each part using perl or ksh code.
node 1 {
entry : {perl code}
leaving: {ksh code}
eventX : node 2
}
The all work would be on the eventX , how to create one in a cron like
process, how to bind the superb kqueue, and
how to get notified from the network states change.
Now , if ifstated is not able to handle what it was design for (CARP)
i guess it should be fixed.
--
-
() ascii ribbon campaign - against html e-mail
/\
Re: ifstated(8) improvement
Em 09-06-2014 12:03, sven falempin escreveu:
ifstated is a cool FSM emgine for handling the carp problems,
for more complex need , instead of hacking this not complete FSM engine,
i would just used another software.
The last time, i just use plain perl script, because it was convenient
and easy to read,
using a true FSM design was just making the logic more complex.
IMHO the way to improve ifstated is to fork it so it becomes a full FSM
engine,
with transition and node definition, and each part using perl or ksh code.
node 1 {
entry : {perl code}
leaving: {ksh code}
eventX : node 2
}
The all work would be on the eventX , how to create one in a cron like
process, how to bind the superb kqueue, and
how to get notified from the network states change.
Now , if ifstated is not able to handle what it was design for (CARP)
i guess it should be fixed.
It definitively does what it was designed for. But I believe that these
improvements would also benefit carp only deployments. If a carp node is
failing more than N times in the last few minutes, it might be a good
idea to completely fail it over and enter on a different state. I use my
ifstated setup for both carp and isp link failure detection. I took a
look at ifstated code and I've been fiddling with it for a little time
now. I believe that the counter based approach is easy to implement with
less disruption. The time based one is more difficult. As I mentioned,
I've been using ifstated for years now (10+ IIRC). And more often than
not, isp links behave erratic. Carp can also have problems if the
network hardware underneath it does not behave correctly. I don't
believe that all of these situations can be solved even with a true FSM.
That's why I'm proposing these improvements. But, I wanted to discuss
with you guys here on tech@ first. Perhaps something entirely different
needs to be done.
Cheers,
--
Giancarlo Razzolini
GPG: 4096R/77B981BC
Re: ifstated(8) improvement
On Mon, Jun 9, 2014 at 11:17 AM, Giancarlo Razzolini
grazzol...@gmail.com wrote:
Em 09-06-2014 12:03, sven falempin escreveu:
ifstated is a cool FSM emgine for handling the carp problems,
for more complex need , instead of hacking this not complete FSM engine,
i would just used another software.
The last time, i just use plain perl script, because it was convenient
and easy to read,
using a true FSM design was just making the logic more complex.
IMHO the way to improve ifstated is to fork it so it becomes a full FSM
engine,
with transition and node definition, and each part using perl or ksh code.
node 1 {
entry : {perl code}
leaving: {ksh code}
eventX : node 2
}
The all work would be on the eventX , how to create one in a cron like
process, how to bind the superb kqueue, and
how to get notified from the network states change.
Now , if ifstated is not able to handle what it was design for (CARP)
i guess it should be fixed.
It definitively does what it was designed for. But I believe that these
improvements would also benefit carp only deployments. If a carp node is
failing more than N times in the last few minutes, it might be a good
idea to completely fail it over and enter on a different state. I use my
ifstated setup for both carp and isp link failure detection. I took a
look at ifstated code and I've been fiddling with it for a little time
now. I believe that the counter based approach is easy to implement with
less disruption. The time based one is more difficult. As I mentioned,
I've been using ifstated for years now (10+ IIRC). And more often than
not, isp links behave erratic. Carp can also have problems if the
network hardware underneath it does not behave correctly. I don't
believe that all of these situations can be solved even with a true FSM.
That's why I'm proposing these improvements. But, I wanted to discuss
with you guys here on tech@ first. Perhaps something entirely different
needs to be done.
Detecting bad network is problematic, i try to access external service for this,
dns and tcp, this can be done inside ifstated.
For the counter, you could use a file and modified it from ifstated,
and do a if grep 10 /my/file
echo my file reach 10| mail -s alert root; call real action; erase file,
but lets wait for people with more insight :-)
--
-
() ascii ribbon campaign - against html e-mail
/\
Re: Fix ia64 cross-gcc
On Mon, May 26, 2014 at 06:31:45PM +0200, Tobias Ulmer wrote: I want to experiment with building some simple efi binaries. This diff unbreaks make -f Makefile.cross TARGET=ia64 cross-gcc OK? Index: sys/arch/ia64/Makefile === RCS file: sys/arch/ia64/Makefile diff -N sys/arch/ia64/Makefile --- /dev/null 1 Jan 1970 00:00:00 - +++ sys/arch/ia64/Makefile26 May 2014 16:20:15 - @@ -0,0 +1,3 @@ +# $OpenBSD$ + +.include bsd.prog.mk You can go ahead as far as I'm concerned with this part. Index: lib/libcrypto/crypto/arch/ia64/opensslconf.h === RCS file: lib/libcrypto/crypto/arch/ia64/opensslconf.h diff -N lib/libcrypto/crypto/arch/ia64/opensslconf.h --- /dev/null 1 Jan 1970 00:00:00 - +++ lib/libcrypto/crypto/arch/ia64/opensslconf.h 26 May 2014 16:20:15 - @@ -0,0 +1,3 @@ +/* $OpenBSD$ */ + +#error Dummy header, create a proper ia64 config
Re: ifstated(8) improvement
Em 09-06-2014 12:25, sven falempin escreveu: Detecting bad network is problematic, i try to access external service for this, dns and tcp, this can be done inside ifstated. Do this already, in the same and different ways. It all depends on what's available for network failure detection on the site. I always prefer snmp for this. But there are sites where it's not possible to do so. For the counter, you could use a file and modified it from ifstated, and do a if grep 10 /my/file echo my file reach 10| mail -s alert root; call real action; erase file, I use a database for this. Used files in the beginning but improved to a database. But I need to wait a state change and/or I need to have a run every statement that will make the decision. But, since It's only a boolean, I need to have several run every statements to be able to cover all cases. This makes the ifstated daemon a little slower, so the overall link failure detection takes more time. but lets wait for people with more insight :-) Yes. I'll probably hack it anyway. But if more people here on tech@ helps with suggestions/directions, I'll probably do a better job. Thanks in advance for your time. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
fsck_msdos: off by one for FAT12
Hi, our guard pages just told me that writefat is vulnerable to an off by one for FAT12 filesystems. They shouldn't be that common anymore, but better be safe than sorry. The diff looks confusing at first, but this default-block is just split into two cluster blocks, as it's done in readfat (line 176). This diff has an effect on variable p, but from my point of view, it's no issue because it's not used after for-loop anymore -- and the for-loop will stop if cl + 1 boot-NumClusters. Enough talk, here's how to trigger it (i386, 1M iso triggers it for me): Create a 1M filesystem: # dd if=/dev/zero of=poc.iso bs=1M count=1 # vnconfig vnd0c poc.iso # newfs_msdos vnd0c Break FAT and try to repair # dd if=/dev/zero of=poc.iso conv=notrunc bs=1 count=1 seek=512 # fsck_msdos vnd0c Output: ** /dev/rvnd0c (vnd0c) ** Phase 1 - Read and Compare FATs FAT starts with odd byte sequence (00) Correct? [Fyn] y ** Phase 2 - Check Cluster Chains Segmentation fault (core dumped) # _ Tobias Index: fat.c === RCS file: /cvs/src/sbin/fsck_msdos/fat.c,v retrieving revision 1.19 diff -u -p -r1.19 fat.c --- fat.c 9 Jun 2014 09:13:33 - 1.19 +++ fat.c 9 Jun 2014 19:06:26 - @@ -471,13 +471,15 @@ writefat(int fs, struct bootblock *boot, default: if (fat[cl].next == CLUST_FREE) boot-NumFree++; - if (cl + 1 boot-NumClusters -fat[cl + 1].next == CLUST_FREE) - boot-NumFree++; *p++ = (u_char)fat[cl].next; - *p++ = (u_char)((fat[cl].next 8) 0xf) - |(u_char)(fat[cl+1].next 4); - *p++ = (u_char)(fat[++cl].next 4); + *p++ = (u_char)((fat[cl].next 8) 0xf); + cl++; + if (cl = boot-NumClusters) + break; + if (fat[cl].next == CLUST_FREE) + boot-NumFree++; + *p |= (u_char)(fat[cl + 1].next 4); + *p++ = (u_char)(fat[cl + 1].next 4); break; } }
Re: fsck_msdos: off by one for FAT12
On Mon, Jun 09, 2014 at 09:16:42PM +0200, Tobias Stoeckmann wrote: + cl++; [...] + *p |= (u_char)(fat[cl + 1].next 4); + *p++ = (u_char)(fat[cl + 1].next 4); And here the correct diff, cl + 1 must not be done after cl++ ... Index: fat.c === RCS file: /cvs/src/sbin/fsck_msdos/fat.c,v retrieving revision 1.19 diff -u -p -r1.19 fat.c --- fat.c 9 Jun 2014 09:13:33 - 1.19 +++ fat.c 9 Jun 2014 19:06:26 - @@ -471,13 +471,15 @@ writefat(int fs, struct bootblock *boot, default: if (fat[cl].next == CLUST_FREE) boot-NumFree++; - if (cl + 1 boot-NumClusters -fat[cl + 1].next == CLUST_FREE) - boot-NumFree++; *p++ = (u_char)fat[cl].next; - *p++ = (u_char)((fat[cl].next 8) 0xf) - |(u_char)(fat[cl+1].next 4); - *p++ = (u_char)(fat[++cl].next 4); + *p++ = (u_char)((fat[cl].next 8) 0xf); + cl++; + if (cl = boot-NumClusters) + break; + if (fat[cl].next == CLUST_FREE) + boot-NumFree++; + *p |= (u_char)(fat[cl].next 4); + *p++ = (u_char)(fat[cl].next 4); break; } }
Re: LibreSSL: is there any reason to keep opaque_prf_input?
Hello,
I just noticed r1.44 to t1_lib.c. I'm not sure that auditing
opaque_prf_input is a good use of anyone's time -- I think it might be
better to just run unifdef -U TLSEXT_TYPE_opaque_prf_input and be done
with it.
Here's the history of opaque_prf_input as I understand it:
- In 2006, the Department of Defense wanted a TLS extension that could
provide extra random inputs for generating the master secret. A draft
was produced for an extension that would let the client and server
each contribute up to 64 KB of extra random material to the PRF. [1]
- The draft was abandoned and expired in June of 2007. No extension type
was ever assigned.
- In September 2007, OpenSSL added support for the expired draft. [2]
Of course, since there's no assigned extension type, users need to
define one and recompile the library to use the extension.
Given that the extension was dead on arrival and implemented
post-mortem, I wouldn't be surprised to discover that opaque_prf_input
has as many users as big-endian amd64 support.
You're right. What about the following diff? (major bump for libssl)
Index: src/apps/s_cb.c
===
RCS file: /cvs/src/lib/libssl/src/apps/s_cb.c,v
retrieving revision 1.20
diff -u -p -r1.20 s_cb.c
--- src/apps/s_cb.c 18 May 2014 16:21:03 - 1.20
+++ src/apps/s_cb.c 9 Jun 2014 19:44:44 -
@@ -696,11 +696,6 @@ tlsext_cb(SSL * s, int client_server, in
extname = renegotiation info;
break;
-#ifdef TLSEXT_TYPE_opaque_prf_input
- case TLSEXT_TYPE_opaque_prf_input:
- extname = opaque PRF input;
- break;
-#endif
#ifdef TLSEXT_TYPE_next_proto_neg
case TLSEXT_TYPE_next_proto_neg:
extname = next protocol;
Index: src/apps/s_client.c
===
RCS file: /cvs/src/lib/libssl/src/apps/s_client.c,v
retrieving revision 1.59
diff -u -p -r1.59 s_client.c
--- src/apps/s_client.c 2 Jun 2014 16:23:18 - 1.59
+++ src/apps/s_client.c 9 Jun 2014 19:44:45 -
@@ -910,11 +910,6 @@ bad:
}
#endif
/* SSL_set_cipher_list(con,RC4-MD5); */
-#if 0
-#ifdef TLSEXT_TYPE_opaque_prf_input
- SSL_set_tlsext_opaque_prf_input(con, Test client, 11);
-#endif
-#endif
re_start:
Index: src/apps/s_server.c
===
RCS file: /cvs/src/lib/libssl/src/apps/s_server.c,v
retrieving revision 1.51
diff -u -p -r1.51 s_server.c
--- src/apps/s_server.c 2 Jun 2014 16:23:18 - 1.51
+++ src/apps/s_server.c 9 Jun 2014 19:44:45 -
@@ -1541,11 +1541,6 @@ sv_body(char *hostname, int s, unsigned
strlen((char *) context));
}
SSL_clear(con);
-#if 0
-#ifdef TLSEXT_TYPE_opaque_prf_input
- SSL_set_tlsext_opaque_prf_input(con, Test server, 11);
-#endif
-#endif
if (SSL_version(con) == DTLS1_VERSION) {
Index: src/ssl/s3_lib.c
===
RCS file: /cvs/src/lib/libssl/src/ssl/s3_lib.c,v
retrieving revision 1.57
diff -u -p -r1.57 s3_lib.c
--- src/ssl/s3_lib.c7 Jun 2014 14:40:55 - 1.57
+++ src/ssl/s3_lib.c9 Jun 2014 19:44:47 -
@@ -2322,11 +2322,6 @@ ssl3_free(SSL *s)
if (s == NULL)
return;
-#ifdef TLSEXT_TYPE_opaque_prf_input
- free(s-s3-client_opaque_prf_input);
- free(s-s3-server_opaque_prf_input);
-#endif
-
ssl3_cleanup_key_block(s);
ssl3_release_read_buffer(s);
ssl3_release_write_buffer(s);
@@ -2351,13 +2346,6 @@ ssl3_clear(SSL *s)
size_t rlen, wlen;
int init_extra;
-#ifdef TLSEXT_TYPE_opaque_prf_input
- free(s-s3-client_opaque_prf_input);
- s-s3-client_opaque_prf_input = NULL;
- free(s-s3-server_opaque_prf_input);
- s-s3-server_opaque_prf_input = NULL;
-#endif
-
ssl3_cleanup_key_block(s);
if (s-s3-tmp.ca_names != NULL)
sk_X509_NAME_pop_free(s-s3-tmp.ca_names, X509_NAME_free);
@@ -2570,35 +2558,6 @@ ssl3_ctrl(SSL *s, int cmd, long larg, vo
ret = 1;
break;
-#ifdef TLSEXT_TYPE_opaque_prf_input
- case SSL_CTRL_SET_TLSEXT_OPAQUE_PRF_INPUT:
- if (larg 12288) {
- /*
-* Actual internal limit is 2^16 for the complete
-* hello message (including the cert chain and
-* everything)
-*/
- SSLerr(SSL_F_SSL3_CTRL,
- SSL_R_OPAQUE_PRF_INPUT_TOO_LONG);
- break;
- }
- free(s-tlsext_opaque_prf_input);
- if ((size_t)larg == 0) {
- s-tlsext_opaque_prf_input = NULL;
- s-tlsext_opaque_prf_input_len = 0;
-
Re: new OpenSSL flaws
Alexander, I'd like to thank you for taking the time to answer Theo's questions, the further advice you've given here, for your patience and the work that you do overall. Regards, -- Steven Chamberlain ste...@pyro.eu.org
increase netcat's buffer...
So, I was using nc (on FreeBSD) to image an HD over the network and
it was consuming much cpu. It turns out that the buffer used by netcat
is only 2k in size, though the buffer on the stack is 16k.
This patch increased plan to use the entire buffer:
--- netcat.obsd.c.orig 2014-05-19 18:25:23.0 -0700
+++ netcat.obsd.c 2014-06-09 20:07:31.0 -0700
@@ -738,7 +738,7 @@
int lfd = fileno(stdout);
int plen;
- plen = 2048;
+ plen = sizeof buf;
/* Setup Network FD */
pfd[0].fd = nfd;
A better patch is probably the following which also increases the size
of the buffer to at least 64k:
--- netcat.obsd.c.orig 2014-05-19 18:25:23.0 -0700
+++ netcat.obsd.c 2014-06-09 20:11:56.0 -0700
@@ -733,12 +733,12 @@
readwrite(int nfd)
{
struct pollfd pfd[2];
- unsigned char buf[16384];
+ unsigned char buf[64*1024];
int n, wfd = fileno(stdin);
int lfd = fileno(stdout);
int plen;
- plen = 2048;
+ plen = sizeof buf;
/* Setup Network FD */
pfd[0].fd = nfd;
I would like to apply the following patch to FreeBSD, but it'd be nice
to keep these changes to a minimum between the two.
Thanks.
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
Re: increase netcat's buffer...
On Mon, Jun 09, 2014 at 20:12, John-Mark Gurney wrote: A better patch is probably the following which also increases the size of the buffer to at least 64k: Agreed.
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.
