similar to: PATCH: update version to p2 in version.h

Hi, So I screwed up when writing the support for the curve25519 KEX method that doesn't depend on OpenSSL's BIGNUM type - a bug in my code left leading zero bytes where they should have been skipped. The impact of this is that OpenSSH 6.5 and 6.6 will fail during key exchange with a peer that implements curve25519-sha256 at libssh.org properly about 0.2% of the time (one in every 512ish

https://bugzilla.mindrot.org/show_bug.cgi?id=3608 Bug ID: 3608 Summary: ssh version is different with sshd version Product: Portable OpenSSH Version: 9.3p2 Hardware: amd64 OS: Linux Status: NEW Severity: normal Priority: P5 Component: sshd Assignee: unassigned-bugs at

6.2p2 prints the same version string in the debugging output as it does when invoked with -V: % ssh -V OpenSSH_6.2p2, OpenSSL 0.9.8y 5 Feb 2013 % ssh -v nonesuch |& head -1 OpenSSH_6.2p2, OpenSSL 0.9.8y 5 Feb 2013 6.3p1 and newer don't - I don't have anything at hand that runs 6.3p1, but here are 6.[456]p1: % ssh -V OpenSSH_6.4p1, OpenSSL 1.0.1e-freebsd 11 Feb 2013 % ssh -v

hi, i think that sftp-server should work fine, even if there are no 64 bit integers, just try 32 bit and panic if the top bit's are set... -------------- next part -------------- An embedded message was scrubbed... From: Brian Candler <B.Candler at pobox.com> Subject: Re: compatibility problem between openssh2.5.1 p1 or p2 and ssf Date: Sun, 4 Mar 2001 21:28:28 +0000 Size: 2221 Url:

Hey, I'm trying to build something like this http://flowingdata.com/2011/05/11/how-to-map-connections-with-great-circles/ but with my own data in csv files. The code runs well if I use the same csv files as the author, but with mine , this is what I get *Code* library(maps) library(geosphere) map("world") xlim <- c(-180.00, 180.00) ylim <- c(-90.00, 90.00)

(These are compiling the .src.rpm from ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/rpm/SRPMS/openssh-3.7.1p1-1.src.rpm) 1) On Red Hat 7.3, with gcc-3.2 with the SSP patch (http://www.research.ibm.com/trl/projects/security/ssp/), rpm --rebuild --define "static_libcrypto 1" openssh-3.7.1p1-1.src.rpm - I needed to add -ldl to the linker flags before it linked. 2)

On Tue, Jan 12, 2016 at 12:45:14PM -0800, Leonid Yegoshin wrote: > >The issue I have with the SYNC description in the text above is that it > >describes the single CPU (program order) and the dual-CPU (confusingly > >named global order) cases, but then doesn't generalise any further. That > >means we can't sensibly reason about transitivity properties when a third

libswfdec/swfdec_as_interpret.c | 2 - libswfdec/swfdec_as_interpret.h | 6 ++++ libswfdec/swfdec_movie.c | 8 ++++- libswfdec/swfdec_system_as.c | 6 +++- libswfdec/swfdec_text_field_movie.c | 42 ++++++++++++++++++++++++++--- test/trace/Makefile.am | 7 ++++ test/trace/text-field-variable-6.swf

Hi, version.h of the 3.3p1 portable release, and of (yesterday's) CVS tree says #define SSH_VERSION "OpenSSH_3.3" and not "OpenSSH_3.3p1". Is this an oversight, or are portable releases not tagged anymore? (I'm asking because I used this to distinguish between the different FreeBSD ports - "openbsd openssh" and "portable", which is harder

On Tue, Jan 26, 2016 at 12:10:10PM +0000, Will Deacon wrote: > On Mon, Jan 25, 2016 at 05:06:46PM -0800, Paul E. McKenney wrote: > > On Mon, Jan 25, 2016 at 02:41:34PM +0000, Will Deacon wrote: > > > On Fri, Jan 15, 2016 at 11:28:45AM -0800, Paul E. McKenney wrote: > > > > On Fri, Jan 15, 2016 at 09:54:01AM -0800, Paul E. McKenney wrote: > > > > > On

On Tue, Jan 26, 2016 at 12:10:10PM +0000, Will Deacon wrote: > On Mon, Jan 25, 2016 at 05:06:46PM -0800, Paul E. McKenney wrote: > > On Mon, Jan 25, 2016 at 02:41:34PM +0000, Will Deacon wrote: > > > On Fri, Jan 15, 2016 at 11:28:45AM -0800, Paul E. McKenney wrote: > > > > On Fri, Jan 15, 2016 at 09:54:01AM -0800, Paul E. McKenney wrote: > > > > > On

On Mon, Jan 25, 2016 at 05:06:46PM -0800, Paul E. McKenney wrote: > On Mon, Jan 25, 2016 at 02:41:34PM +0000, Will Deacon wrote: > > On Fri, Jan 15, 2016 at 11:28:45AM -0800, Paul E. McKenney wrote: > > > On Fri, Jan 15, 2016 at 09:54:01AM -0800, Paul E. McKenney wrote: > > > > On Fri, Jan 15, 2016 at 10:24:32AM +0000, Will Deacon wrote: > > > > > See

(I try to answer on multiple mails in one) First of all, it seems like some generic notes should be given here: 1. Generic MIPS "SYNC" (aka "SYNC 0") instruction is a very heavy in some CPUs. On that CPUs it basically kills pipelines in each CPU, can do a special memory/IO bus transaction (similar to "fence") and hold a system until all R/W is completed. It is

On Mon, Jan 25, 2016 at 02:41:34PM +0000, Will Deacon wrote: > On Fri, Jan 15, 2016 at 11:28:45AM -0800, Paul E. McKenney wrote: > > On Fri, Jan 15, 2016 at 09:54:01AM -0800, Paul E. McKenney wrote: > > > On Fri, Jan 15, 2016 at 10:24:32AM +0000, Will Deacon wrote: > > > > See my earlier reply [1] (but also, your WRC Linux example looks more > > > > like a

On Mon, Jan 25, 2016 at 02:41:34PM +0000, Will Deacon wrote: > On Fri, Jan 15, 2016 at 11:28:45AM -0800, Paul E. McKenney wrote: > > On Fri, Jan 15, 2016 at 09:54:01AM -0800, Paul E. McKenney wrote: > > > On Fri, Jan 15, 2016 at 10:24:32AM +0000, Will Deacon wrote: > > > > See my earlier reply [1] (but also, your WRC Linux example looks more > > > > like a

On Tue, Jan 26, 2016 at 12:16:09PM +0000, Will Deacon wrote: > On Mon, Jan 25, 2016 at 10:03:22PM -0800, Paul E. McKenney wrote: > > On Mon, Jan 25, 2016 at 04:42:43PM +0000, Will Deacon wrote: > > > On Fri, Jan 15, 2016 at 01:58:53PM -0800, Paul E. McKenney wrote: > > > > PPC Overlapping Group-B sets version 4 > > > > "" > > > > (*

On Tue, Jan 26, 2016 at 12:16:09PM +0000, Will Deacon wrote: > On Mon, Jan 25, 2016 at 10:03:22PM -0800, Paul E. McKenney wrote: > > On Mon, Jan 25, 2016 at 04:42:43PM +0000, Will Deacon wrote: > > > On Fri, Jan 15, 2016 at 01:58:53PM -0800, Paul E. McKenney wrote: > > > > PPC Overlapping Group-B sets version 4 > > > > "" > > > > (*

On Mon, Jan 25, 2016 at 10:03:22PM -0800, Paul E. McKenney wrote: > On Mon, Jan 25, 2016 at 04:42:43PM +0000, Will Deacon wrote: > > On Fri, Jan 15, 2016 at 01:58:53PM -0800, Paul E. McKenney wrote: > > > PPC Overlapping Group-B sets version 4 > > > "" > > > (* When the Group-B sets from two different barriers involve instructions in > > >

On Tue, Jan 26, 2016 at 11:58:20AM -0800, Paul E. McKenney wrote: > On Tue, Jan 26, 2016 at 12:16:09PM +0000, Will Deacon wrote: > > On Mon, Jan 25, 2016 at 10:03:22PM -0800, Paul E. McKenney wrote: > > > On Mon, Jan 25, 2016 at 04:42:43PM +0000, Will Deacon wrote: > > > > On Fri, Jan 15, 2016 at 01:58:53PM -0800, Paul E. McKenney wrote: > > > > > PPC

On Wed, Jan 13, 2016 at 02:26:16PM -0800, Leonid Yegoshin wrote: > On 01/13/2016 02:45 AM, Will Deacon wrote: > >> > >I don't think the address dependency is enough on its own. By that > >reasoning, the following variant (WRC+addr+addr) would work too: > > > > > >P0: > >Wx = 1 > > > >P1: > >Rx == 1 > ><address dep>