Re: OpenSSH HPN

[Dag-Erling Smørgrav]

Bryan Drewery  writes:
> Actually I am missing the client-side VersionAddendum support (ssh.c). I
> only have server-side (sshd.c).  This is just due to lack of motivation
> to import the changes.

Pretty sure I sent Damien the patch a few years ago...  There was also a
bug in the server-side code (IIRC, one place where it printed only the
hardcoded version instead of the variable string).  I'll try again.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

regression in igb/clang?

[Alexander Leidinger]

Hi,

I' updated a system with -current as of r287323 (end August) to r290633
(yesterday).

Result: no network connection (not even ping) on igb.
Ping internally (local addresses) works, anything outgoing/incoming
doesn't.

I disabled HW support (tso4, lro, rxcsum, txcsum): doesn't help.

Did I miss some known defect/workaround?

Anything I should test/provide besides what is below?

The igb device is a:
---snip---
igb0@pci0:1:0:0: class=0x02 card=0x34e28086 chip=0x10a78086 rev=0x02 
hdr=0x00
---snip---

My src.conf:
---snip---
WITH_IDEA=yes
WITHOUT_PROFILE=yes
CFLAGS+=-DFTP_COMBINE_CWDS
MALLOC_PRODUCTION=yes
LOADER_FIREWIRE_SUPPORT=yes
#WITH_FAST_DEPEND=yes
---snip---

My buildworld related config in make.conf:
---snip---
CFLAGS+= -O2 -pipe
COPTFLAGS= -O2 -pipe
#CPUTYPE?=core2
#WITH_CCACHE_BUILD=yes
#.if (!empty(.CURDIR:M/usr/src*)
|| !empty(.CURDIR:M/usr/obj*)|| !empty(.CURDIR:M/space/system/usr_obj*))
#.if !defined(NOCCACHE) && exists(/usr/local/libexec/ccache/world/cc)
#CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1}
#CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1} #.endif
#.endif
---snip---

The commented out parts were active initially, but then I commented
them out, cleaned out /usr/obj (rm -r) and rebuild/reinstall to make
sure it's not due to them (CPUTYPE commented out due to the fact that
there's a new compiler, and I use zsh and there was a commit talking
about zsh and CPUTYPE workaround).

Bye,
Alexander.

-- 
http://www.Leidinger.net alexan...@leidinger.net: PGP 0xC773696B3BAC17DC
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0xC773696B3BAC17DC
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Ben Woods]

On Wednesday, 11 November 2015, John-Mark Gurney  wrote:

> Ben Woods wrote this message on Wed, Nov 11, 2015 at 15:40 +0800:
> > I have to agree that there are cases when the NONE cipher makes sense,
> and
> > it is up to the end user to make sure they know what they are doing.
> >
> > Personally I have used it at home to backup my old FreeBSD server (which
> > does not have AESNI) over a dedicated network connection to a backup
> server
> > using rsync/ssh. Since it was not possible for anyone else to be on that
> > local network, and the server was so old it didn't have AESNI and would
> > soon be retired, using the NONE cipher sped up the transfer
> significantly.
>
> If you have a trusted network, why not just use nc?
>

Honest answer: ignorance of how I can use netcat together with rsync.


-- 

--
From: Benjamin Woods
woods...@gmail.com
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD_HEAD-tests - Build #1681 - Still Unstable

[jenkins-admin]

FreeBSD_HEAD-tests - Build #1681 - Still Unstable:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1681/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1681/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1681/console

Change summaries:

No changes


The failed test cases:

5 tests failed.
FAILED:  bin.sh.builtins.functional_test.case7

Error Message:
atf-check failed; see the output of the test for details

FAILED:  bin.sh.builtins.functional_test.locale1

Error Message:
atf-check failed; see the output of the test for details

FAILED:  lib.libc.locale.c16rtomb_test.c16rtomb_test

Error Message:
Premature exit; test case received signal 11 (core dumped)

FAILED:  lib.libc.locale.mbrtoc16_test.mbrtoc16_test

Error Message:
Premature exit; test case received signal 11 (core dumped)

FAILED:  
lib.libc.stdio.printfloat_test.thousands_separator_and_other_locale_tests

Error Message:
printf("%'.4f", 12345678.0625) ==> [1,23,45,678.0625], expected 
[123,456,78.0625]<>

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Julian Elischer]

On 11/10/15 5:42 PM, Dag-Erling Smørgrav wrote:

Some of you may have noticed that OpenSSH in base is lagging far behind
the upstream code.

The main reason for this is the burden of maintaining the HPN patches.
They are extensive, very intrusive, and touch parts of the OpenSSH code
that change significantly in every release.  Since they are not
regularly updated, I have to choose between trying to resolve the
conflicts myself (hoping I don't break anything) or waiting for them to
catch up and then figuring out how to apply the new version.

Therefore, I would like to remove the HPN patches from base and refer
anyone who really needs them to the openssh-portable port, which has
them as a default option.  I would also like to remove the NONE cipher
patch, which is also available in the port (off by default, just like in
base).

DES
The inclusion of the HPN patches meant that we could drop a custom 
unsupported HPN enabled ssh from our build process.

It makes ssh actually usable.
Without it we need to keep integrating HPN ever time ssh is upgraded.

We were SO HAPPY when it came in by default.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Julian Elischer]

On 11/10/15 7:16 PM, Dag-Erling Smørgrav wrote:

Bob Bishop  writes:

Is removing HPN going to impact the performance of tunnelled X
connexions?


yes if your rtt is greater than about 85 mSec
I don't know he details but I noticed a big difference.
I had thought X wouldn't show much difference but in fact it did.
At work we had to add HPN to get anything like acceptable performance
on various tunnels our appliance uses.

I don't think so.  It mostly affects the performance of long
unidirectional streams (file transfers) whereas the X protocol, as far
as I know, is a bidirectional exchange of relatively short messages.  It
may make a difference for applications that transfer large textures...
I don't really know enough about the X protocol to say for certain, but
I am typing this in Emacs over a non-HPN SSH connection, and I regularly
tunnel Firefox between the same two machines (RHEL 7 desktop at work and
FreeBSD 10 desktop at home).

DES


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Mark Martinec]

For a fast transfer of large files see sysutils/bbcp.

It uses ssh to establish authorized connection, then does
a transfer over multiple parallel TCP sessions by itself.

If data encryption is needed, combine it with security/hpenc

  Mark
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Build failed in Jenkins: Build-UFS-image #2711

[jenkins-admin]

See 

--
Started by upstream project "Build_Image_and_Run_Tests_in_Bhyve_HEAD" build 
number 1753
originally caused by:
 Started by upstream project "FreeBSD_HEAD" build number 3511
 originally caused by:
  Started by an SCM change
Building remotely on jenkins-10.freebsd.org (FreeBSD-10)No JDK named ?null? 
found
 in workspace 
No JDK named ?null? found
No JDK named ?null? found
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/freebsd/freebsd-ci # 
 > timeout=10
Fetching upstream changes from https://github.com/freebsd/freebsd-ci
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > https://github.com/freebsd/freebsd-ci +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 65a323ece2701c4a650ed241aea8bdecfaf56ea9 
(refs/remotes/origin/master)
No JDK named ?null? found
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 65a323ece2701c4a650ed241aea8bdecfaf56ea9
 > git rev-list 65a323ece2701c4a650ed241aea8bdecfaf56ea9 # timeout=10
No JDK named ?null? found
[Build-UFS-image] $ /bin/sh -xe /tmp/hudson5654695980704501244.sh
+ freebsd-ci/scripts/build/build-ufs-image.sh
+ [ -z  ]
+ [ -z /builds/FreeBSD_HEAD ]
+ [ -z '' ]
+ export MAKEOBJDIRPREFIX=/builds/FreeBSD_HEAD/obj
+ [ -z '' ]
+ basename /builds/FreeBSD_HEAD
+ 
PACKAGE_ROOT=
+ [ -z '' ]
+ basename /builds/FreeBSD_HEAD
+ 
IMAGE_ROOT=
+ [ -n '' ]
+ [ -z /builds/FreeBSD_HEAD/obj ]
+ cd /builds/FreeBSD_HEAD
+ [ -z '' ]
+ [ -f /builds/FreeBSD_HEAD/make.conf ]
+ __MAKE_CONF=/builds/FreeBSD_HEAD/make.conf
+ sudo rm -fr 

rm: 
:
 Operation not permitted
rm: 
: 
Directory not empty
rm: : 
Directory not empty
Build step 'Execute shell' marked build as failure
No JDK named ?null? found
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Bryan Drewery]

On 11/11/2015 10:13 AM, Slawa Olhovchenkov wrote:
> On Wed, Nov 11, 2015 at 05:51:25PM +0100, Dag-Erling Smørgrav wrote:
> 
>> Bryan Drewery  writes:
>>> Another thing that I did with the port was restore the tcpwrapper
>>> support that upstream removed. Again, if we decide it is not worth
>>> keeping in base I will remove it as default in the port.
>>
>> I want to keep tcpwrapper support - it is another reason why I still
>> haven't upgraded OpenSSH, but to the best of my knowledge, it is far
>> less intrusive than HPN.
> 
> Can you explain what is problem?
> I am see openssh in base and openssh in ports (more recent version)
> with same functionaly patches.
> You talk about trouble to upgrade. What is root?
> openssh in base have different vendor and/or license?
> Or something else?
> 
> PS: As I today know, kerberos heimdal is practicaly dead as opensource
> project. Have FreeBSD planed switch to MIT Kerberos?
> I am know about security/krb5.
> 

IMHO the problem comes down to time. Patching an upstream project
increases maintenance cost for upgrading it. Every patch adds up. When
you become busy and don't have time to pay attention to every little
change made in a release, hearing 'removed tcpwrappers support' or
'refactored the code  for libssh usage' makes it sound like 1 more
thing you must deal with to upgrade that code base and more effort to
validate that your patches are right. We obviously don't want to just
drop in the latest code and throw it out there as broken. SSH is quite
critical and we want to ensure our changes are still right, and that
doing something like adding tcpwrappers back in won't introduce some
security bug that upstream was coy about.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: OpenSSH HPN

[Bryan Drewery]

On 11/11/2015 1:04 AM, Dag-Erling Smørgrav wrote:
> Ben Woods  writes:
>> Personally I have used it at home to backup my old FreeBSD server
>> (which does not have AESNI) over a dedicated network connection to a
>> backup server using rsync/ssh. Since it was not possible for anyone
>> else to be on that local network, and the server was so old it didn't
>> have AESNI and would soon be retired, using the NONE cipher sped up
>> the transfer significantly.
> 
> In that scenario, you don't need ssh at all.  Just set up rsyncd on the
> backup server.
> 

Yes, it's more a matter of convenience with key management. I admit that
after some recent changes I've made I did resort to using the base SSH
and rsync:// to achieve my backups over VPN out of not wanting to
customize the the new system further with the port version or rebuilding
base.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: OpenSSH HPN

[Bryan Drewery]

On 11/10/2015 3:48 AM, Dag-Erling Smørgrav wrote:
> Willem Jan Withagen  writes:
>> "Dag-Erling Smørgrav"  writes:
>>> Willem Jan Withagen  writes:
 Are they still willing to accept changes to the old version that
 is currently in base?
>>> No, why would they do that?
>> Exactly my question  I guess I misinterpreted your suggestion on
>> upstreaming patches.
> 
> I didn't suggest submitting patches, I suggested submitting a feature
> request.  Damien is generally pretty open to suggestions.
> 

My own experience here has been positive, both with patches, feature
suggestion, and general discussion. The upstream is more open than
people may think.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: OpenSSH HPN

[Dag-Erling Smørgrav]

Daniel Kalchev  writes:
> I must have missed the explanation. But why having a NONE cypher
> compiled in, but disabled in the configuration is a bad idea?

It increases the cost of maintaining OpenSSH in base noticeably without
providing real value unless you are one of the few people who need HPN
and lack the CPU power to perform encryption at line speed.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

bsd.subdir.mk: Recursing on dependent targets

[Bryan Drewery]

The current behavior of bsd.subdir.mk has a very surprising behavior
that I think is wrong and think that changing it will have no real impact.

Consider:

SUBDIR_TARGETS= all foo

all: foo

If you call 'make foo' it will recurse 'foo' on all sub-directories as
expected.

If you call 'make all' it will recurse 'foo' in all sub-directories and
then recurse 'all' in all sub-directories which then again calls 'foo'
in sub-directories! So technically 'foo' is called 3 times in some
directories do to 'all' implicitly calling it as well.

Here's a contrived example with 'all' and 'buildconfig' which is prone
to this problem now.

~/svn/base/usr.bin/bsdiff # make all|grep buildconfig|grep bsdiff/subdir
===> bsdiff/subdir (buildconfig)
buildconfig=/root/svn/base/usr.bin/bsdiff/bsdiff/subdir
===> bsdiff/subdir (buildconfig)
buildconfig=/root/svn/base/usr.bin/bsdiff/bsdiff/subdir
buildconfig=/root/svn/base/usr.bin/bsdiff/bsdiff/subdir

Full:
~/svn/base/usr.bin/bsdiff # make all
===> bsdiff (buildconfig)
===> bsdiff/subdir (buildconfig)
buildconfig=/root/svn/base/usr.bin/bsdiff/bsdiff/subdir
buildconfig=/root/svn/base/usr.bin/bsdiff/bsdiff
===> bspatch (buildconfig)
buildconfig=/root/svn/base/usr.bin/bsdiff/bspatch
buildconfig=/root/svn/base/usr.bin/bsdiff
===> bsdiff (all)
===> bsdiff/subdir (buildconfig)
buildconfig=/root/svn/base/usr.bin/bsdiff/bsdiff/subdir
buildconfig=/root/svn/base/usr.bin/bsdiff/bsdiff
===> bsdiff/subdir (all)
buildconfig=/root/svn/base/usr.bin/bsdiff/bsdiff/subdir
===> bspatch (all)
buildconfig=/root/svn/base/usr.bin/bsdiff/bspatch



With the change I would like to make, to only recurse on *called*
targets, the result is:

~/svn/base/usr.bin/bsdiff # make all|grep buildconfig|grep bsdiff/subdir
buildconfig=/root/svn/base/usr.bin/bsdiff/bsdiff/subdir

~/svn/base/usr.bin/bsdiff # make all
buildconfig=/root/svn/base/usr.bin/bsdiff
===> bsdiff (all)
buildconfig=/root/svn/base/usr.bin/bsdiff/bsdiff
===> bsdiff/subdir (all)
buildconfig=/root/svn/base/usr.bin/bsdiff/bsdiff/subdir
===> bspatch (all)
buildconfig=/root/svn/base/usr.bin/bsdiff/bspatch



The potential problem I see with this is if someone has some top-level
target like 'buildit' that is not in SUBDIR_TARGETS but it depends on
targets which are in SUBDIR_TARGETS, such as 'all'. This would now no
longer recurse on those.  I think this would be worth an UPDATING entry
that 'buildit' needs to be added into SUBDIR_TARGETS or called
explicitly with ${MAKE}, but I also want to be sure I'm not missing
something here about this being 'expected behavior'. From my own
experience I don't expect this to be an actual problem.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: OpenSSH HPN

[Dag-Erling Smørgrav]

Slawa Olhovchenkov  writes:
> Can you explain what is problem?

Radical suggestion: read the first email in the thread.

> PS: As I today know, kerberos heimdal is practicaly dead as opensource
> project. Have FreeBSD planed switch to MIT Kerberos?  I am know about
> security/krb5.

We switched from MIT to Heimdal at some point in the past for some
reason I don't remember.  MIT and Heimdal are *not* interchangeable at
the source or binary level, so switching back is not trivial.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Bryan Drewery]

On 11/11/2015 1:23 AM, Dag-Erling Smørgrav wrote:
> Bryan Drewery  writes:
>> Actually I am missing the client-side VersionAddendum support (ssh.c). I
>> only have server-side (sshd.c).  This is just due to lack of motivation
>> to import the changes.
> 
> Pretty sure I sent Damien the patch a few years ago...  There was also a
> bug in the server-side code (IIRC, one place where it printed only the
> hardcoded version instead of the variable string).  I'll try again.
> 

By the way, I may have come off wrong. I'm willing to do the work to
update the base version and put it out for review if you would like.

Another thing that I did with the port was restore the tcpwrapper
support that upstream removed. Again, if we decide it is not worth
keeping in base I will remove it as default in the port.

I honestly don't have a strong opinion on keeping or removing HPN. It is
afterall available in the port and I intend to keep it as an option
there. The question is just what the default is.

I prefer to keep the port close to the base version by default options.
I never liked the idea of having 2 different things in the ecosystem
that behave differently, from OpenSSL to OpenSSH, etc.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: OpenSSH HPN

[Dag-Erling Smørgrav]

Bryan Drewery  writes:
> Another thing that I did with the port was restore the tcpwrapper
> support that upstream removed. Again, if we decide it is not worth
> keeping in base I will remove it as default in the port.

I want to keep tcpwrapper support - it is another reason why I still
haven't upgraded OpenSSH, but to the best of my knowledge, it is far
less intrusive than HPN.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: bsd.subdir.mk: Recursing on dependent targets

[Julian H. Stacey]

Hi Bryan & all,
I'm in a rush so will read yours again later, but will quickly mention
I've long ago added a load of *-recursive macros to my Mk/
but never submitted them, they are under
http://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD/ports/gen/Mk/

(but it seems something in apache httpd.conf is truncing file names,
which should appear as eg
bsd.port.subdir.mk.reinstall-recursive.REL=8.2-RELEASE.diff
etc )

Cheers,
Julian
--
Julian Stacey,  BSD Linux Unix Sys. Eng. Consultant Munich http://berklix.com
 Reply After previous text to preserve context, as in a play script.
 Indent previous text with >Insert new lines before 80 chars.
 Use plain text, Not quoted-printable, Not HTML, Not base64, Not MS.doc.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: bsd.subdir.mk: Recursing on dependent targets

[Bryan Drewery]

On 11/11/2015 9:50 AM, Julian H. Stacey wrote:
> Hi Bryan & all,
> I'm in a rush so will read yours again later, but will quickly mention
> I've long ago added a load of *-recursive macros to my Mk/
> but never submitted them, they are under
> http://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD/ports/gen/Mk/
> 
> (but it seems something in apache httpd.conf is truncing file names,
> which should appear as eg
> bsd.port.subdir.mk.reinstall-recursive.REL=8.2-RELEASE.diff
> etc )
> 

This should not be impacted since it does not use bsd.subdir.mk. I'm not
planning to modify bsd.port.subdir.mk at all.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: bsd.subdir.mk: Recursing on dependent targets

[Bryan Drewery]

On 11/11/2015 9:37 AM, Bryan Drewery wrote:
> 
> With the change I would like to make, to only recurse on *called*
> targets

This also has the benefit of no longer having 'realinstall' be a thing
that bsd.subdir.mk needs to care about. Just recursing 'install' would
handle all of the ordering and targets in each subdir.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: OpenSSH HPN

[Slawa Olhovchenkov]

On Wed, Nov 11, 2015 at 05:51:25PM +0100, Dag-Erling Smørgrav wrote:

> Bryan Drewery  writes:
> > Another thing that I did with the port was restore the tcpwrapper
> > support that upstream removed. Again, if we decide it is not worth
> > keeping in base I will remove it as default in the port.
> 
> I want to keep tcpwrapper support - it is another reason why I still
> haven't upgraded OpenSSH, but to the best of my knowledge, it is far
> less intrusive than HPN.

Can you explain what is problem?
I am see openssh in base and openssh in ports (more recent version)
with same functionaly patches.
You talk about trouble to upgrade. What is root?
openssh in base have different vendor and/or license?
Or something else?

PS: As I today know, kerberos heimdal is practicaly dead as opensource
project. Have FreeBSD planed switch to MIT Kerberos?
I am know about security/krb5.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Bryan Drewery]

On 11/11/2015 8:51 AM, Dag-Erling Smørgrav wrote:
> Bryan Drewery  writes:
>> Another thing that I did with the port was restore the tcpwrapper
>> support that upstream removed. Again, if we decide it is not worth
>> keeping in base I will remove it as default in the port.
> 
> I want to keep tcpwrapper support - it is another reason why I still
> haven't upgraded OpenSSH, but to the best of my knowledge, it is far
> less intrusive than HPN.
> 

Yes, it's very small.
/usr/ports/security/openssh-portable/files/extra-patch-tcpwrappers


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: FYI: SVN to GIT converter currently broken, github is falling behind

[Alfred Perlstein]

Lars,

Try to remove .git/gc.log then re-run fetch.

If that doesn't work then move ".git/refs/remotes/origin/HEAD" to backup 
location outside of your .git directory and try again.


-Alfred

On 11/11/15 4:03 AM, Eggert, Lars wrote:

Hi,

I just got this error when fetching from remote; related?

[elars@laurel: ~/src] git fetch --all
Fetching origin
Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
Fetching upstream
remote: Counting objects: 557, done.
remote: Compressing objects: 100% (543/543), done.
remote: Total 557 (delta 213), reused 2 (delta 2), pack-reused 0
Receiving objects: 100% (557/557), 1.15 MiB | 433.00 KiB/s, done.
Resolving deltas: 100% (213/213), completed with 2 local objects.
 From github.com:/freebsd/freebsd
b4eb11a..3eb0ea4  master -> upstream/master
f147893..9c319c0  stable/10  -> upstream/stable/10
e901edd..b3c9fd2  stable/8   -> upstream/stable/8
81ab2b1..2fc7a9a  stable/9   -> upstream/stable/9
c2c933c..cc76737  svn_head   -> upstream/svn_head
Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
error: The last gc run reported the following. Please correct the root cause
and remove .git/gc.log.
Automatic cleanup will not be performed until the file is removed.

fatal: bad object refs/remotes/origin/HEAD
error: failed to run repack

Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
error: The last gc run reported the following. Please correct the root cause
and remove .git/gc.log.
Automatic cleanup will not be performed until the file is removed.

fatal: bad object refs/remotes/origin/HEAD
error: failed to run repack

Lars


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Bryan Drewery]

On 11/11/2015 7:49 AM, Daniel Kalchev wrote:
> It is my understanding, that using the NONE cypher is not identical to using 
> “the old tools” (rsh/rlogin/rcp).
> 
> When ssh uses the NONE cypher, credentials and authorization are still 
> encrypted and verified. Only the actual data payload is not encrypted.
> 
> Perhaps similar level of security could be achieved by “the old tools” if 
> they were by default compiled with Kerberos. Although, this still requires 
> building additional infrastructure.
> 
> I must have missed the explanation. But why having a NONE cypher compiled in, 
> but disabled in the configuration is a bad idea?

My reasoning for wanting SSH/SCP with NONE is precisely because of the
ssh key support. It simplifies a lot to be able to use the same key over
a VPN and not over the VPN to connect to the same system.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: OpenSSH HPN

[Bjoern A. Zeeb]

> On 11 Nov 2015, at 16:53 , Bryan Drewery  wrote:
> 
> On 11/11/2015 8:51 AM, Dag-Erling Smørgrav wrote:
>> Bryan Drewery  writes:
>>> Another thing that I did with the port was restore the tcpwrapper
>>> support that upstream removed. Again, if we decide it is not worth
>>> keeping in base I will remove it as default in the port.
>> 
>> I want to keep tcpwrapper support - it is another reason why I still
>> haven't upgraded OpenSSH, but to the best of my knowledge, it is far
>> less intrusive than HPN.
>> 
> 
> Yes, it's very small.
> /usr/ports/security/openssh-portable/files/extra-patch-tcpwrappers

And thanks to both of you for keeping it.
It’s often the best you can get if you have machines which run w/o firewalls.

Just wanted to say “thanks”!

/bz
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Julian Elischer]

On 11/11/15 7:56 PM, Dag-Erling Smørgrav wrote:

Julian Elischer  writes:

The inclusion of the HPN patches meant that we could drop a custom
unsupported HPN enabled ssh from our build process.  It makes ssh
actually usable.

Define "usable".  Does it actually make a measurable difference with the
latest OpenSSH?  And if HPN is so important to you, is there a reason
why you can't use the port?

useable..  able to use more than 5% of the available bandwidth.

Our environment is not freeBSD exactly. many ports won't compile and 
we don't have ports in our setup (I didn't do it.. don't blame me)
But we do and can compile FreeBSD sourcers so ssh from src is an easy 
recompile or just a binary drop in.
We used to do it by hand from sources ftp'd from OpenBSD and compiled 
straight (no ports),
but since it came to have HPN all that went away because the in-tree 
one worked for us.

Now we'll have to resurrect all that framework and pain.

have you mentioned this plan to Brooks?  Didn't he add it?



DES


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Slawa Olhovchenkov]

On Tue, Nov 10, 2015 at 09:52:16AM -0800, John-Mark Gurney wrote:

> Dag-Erling Smrgrav wrote this message on Tue, Nov 10, 2015 at 10:42 +0100:
> > Therefore, I would like to remove the HPN patches from base and refer
> > anyone who really needs them to the openssh-portable port, which has
> > them as a default option.  I would also like to remove the NONE cipher
> > patch, which is also available in the port (off by default, just like in
> > base).
> 
> My vote is to remove the HPN patches.  First, the NONE cipher made more
> sense back when we didn't have AES-NI widely available, and you were
> seriously limited by it's performance.  Now we have both aes-gcm and
> chacha-poly which it's performance should be more than acceptable for
> today's uses (i.e. cipher performance is 2GB/sec+).
> 
> Second, I did some testing recently due to a thread on -net, and I
> found no significant (not run statistically though) difference in
> performance between in HEAD ssh and OpenSSH 7.1p1.  I started a wiki
> page to talk about this:
> https://wiki.freebsd.org/SSHPerf

Hmm, I see in this page max speed 20MB/sec. This is too small.
What is problem? With modern 40G NIC wanted speed about 20Gbit/s.
10Gbit/s at least.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Slawa Olhovchenkov]

On Tue, Nov 10, 2015 at 11:59:30PM -0800, John-Mark Gurney wrote:

> Ben Woods wrote this message on Wed, Nov 11, 2015 at 15:40 +0800:
> > On Wednesday, 11 November 2015, Bryan Drewery  wrote:
> > 
> > > On 11/10/15 9:52 AM, John-Mark Gurney wrote:
> > > > My vote is to remove the HPN patches.  First, the NONE cipher made more
> > > > sense back when we didn't have AES-NI widely available, and you were
> > > > seriously limited by it's performance.  Now we have both aes-gcm and
> > > > chacha-poly which it's performance should be more than acceptable for
> > > > today's uses (i.e. cipher performance is 2GB/sec+).
> > >
> > > AES-NI doesn't help the absurdity of double-encrypting when using scp or
> > > rsync/ssh over an encrypted VPN, which is where NONE makes sense to use
> > > for me.
> > 
> > I have to agree that there are cases when the NONE cipher makes sense, and
> > it is up to the end user to make sure they know what they are doing.
> > 
> > Personally I have used it at home to backup my old FreeBSD server (which
> > does not have AESNI) over a dedicated network connection to a backup server
> > using rsync/ssh. Since it was not possible for anyone else to be on that
> > local network, and the server was so old it didn't have AESNI and would
> > soon be retired, using the NONE cipher sped up the transfer significantly.
> 
> If you have a trusted network, why not just use nc?

I think you kidding:

- scp need only one command on initiator side and
  no additional setup on target. simple, well know.
- nc need additional work on target, need synchronization for file
  names with target, also need ssh to target for start, etc... Too
  complex.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Dag-Erling Smørgrav]

Julian Elischer  writes:
> Bob Bishop  writes:
> > Is removing HPN going to impact the performance of tunnelled X
> > connexions?
> yes if your rtt is greater than about 85 mSec

With an RTT of 85 ms, X is unusable with or without HPN.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Dag-Erling Smørgrav]

Julian Elischer  writes:
> Now we'll have to resurrect all that framework and pain.

I guess pain is fine as long as it's not yours...

> have you mentioned this plan to Brooks?  Didn't he add it?

These are public lists, but by all means, mention it to him if he hasn't
noticed this thread.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Daniel Kalchev]

It is my understanding, that using the NONE cypher is not identical to using 
“the old tools” (rsh/rlogin/rcp).

When ssh uses the NONE cypher, credentials and authorization are still 
encrypted and verified. Only the actual data payload is not encrypted.

Perhaps similar level of security could be achieved by “the old tools” if they 
were by default compiled with Kerberos. Although, this still requires building 
additional infrastructure.

I must have missed the explanation. But why having a NONE cypher compiled in, 
but disabled in the configuration is a bad idea?

Daniel


> On 11.11.2015 г., at 10:55, Jason Birch  wrote:
> 
> On Wed, Nov 11, 2015 at 6:59 PM, John-Mark Gurney  wrote:
>> If you have a trusted network, why not just use nc?
> 
> Perhaps more generally relevant is that ssh/scp are *waves hands* vaguely
> analogous to secure versions of rsh/rlogin/rcp. I'd think that most cases
> of "I wanted to send files and invoke some commands on a remote machine,
> and due to $CIRCUMSTANCE I don't need or desire encryption" are covered
> by the older, also standard tools. Additionally, rsync can use rsh as its
> transport, for users who desire more advanced behaviour. ssh just seems
> to have more support; Installation will ask you if you'd like to run sshd
> (not rshd), ssh is rather ubiquitous as a way of "doing a thing remotely"
> (even in Windows soon!), etc. This is a good default to have; the
> overhead of security is tiny in nearly all cases.
> 
> It would seem then that the extra complexity of maintenance development
> in supporting NONE in base doesn't really grant us any additional
> functionality in most cases. It's just more 'obvious'.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Jason Birch]

On Wed, Nov 11, 2015 at 6:59 PM, John-Mark Gurney  wrote:
> If you have a trusted network, why not just use nc?

Perhaps more generally relevant is that ssh/scp are *waves hands* vaguely
analogous to secure versions of rsh/rlogin/rcp. I'd think that most cases
of "I wanted to send files and invoke some commands on a remote machine,
and due to $CIRCUMSTANCE I don't need or desire encryption" are covered
by the older, also standard tools. Additionally, rsync can use rsh as its
transport, for users who desire more advanced behaviour. ssh just seems
to have more support; Installation will ask you if you'd like to run sshd
(not rshd), ssh is rather ubiquitous as a way of "doing a thing remotely"
(even in Windows soon!), etc. This is a good default to have; the
overhead of security is tiny in nearly all cases.

It would seem then that the extra complexity of maintenance development
in supporting NONE in base doesn't really grant us any additional
functionality in most cases. It's just more 'obvious'.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Dag-Erling Smørgrav]

Ben Woods  writes:
> Personally I have used it at home to backup my old FreeBSD server
> (which does not have AESNI) over a dedicated network connection to a
> backup server using rsync/ssh. Since it was not possible for anyone
> else to be on that local network, and the server was so old it didn't
> have AESNI and would soon be retired, using the NONE cipher sped up
> the transfer significantly.

In that scenario, you don't need ssh at all.  Just set up rsyncd on the
backup server.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: strange kernel crash

[Andrew Duane]

> -Original Message-
> From: owner-freebsd-hack...@freebsd.org 
> [mailto:owner-freebsd-hack...@freebsd.org] On Behalf Of Andriy Gapon
> Sent: Wednesday, November 11, 2015 3:02 AM
> To: John Baldwin 
> Cc: Hans Petter Selasky ; FreeBSD Hackers 
> ; freebsd-current@FreeBSD.org
> Subject: Re: strange kernel crash
> 
> On 10/11/2015 20:42, John Baldwin wrote:
> > On Tuesday, November 10, 2015 10:48:08 AM Andriy Gapon wrote:
> >> On 09/11/2015 22:16, John Baldwin wrote:
> >>> On Friday, November 06, 2015 07:02:59 PM Hans Petter Selasky wrote:
>  On 11/06/15 12:20, Andriy Gapon wrote:
> > Now the strange part:
> >
> > 0x80619a18 <+744>:   jne0x80619a61 
> > <__mtx_lock_flags+817>
> > 0x80619a1a <+746>:   mov%rbx,(%rsp)
> > => 0x80619a1e <+750>:   movq   $0x0,0x18(%rsp)
> > 0x80619a27 <+759>:   movq   $0x0,0x10(%rsp)
> > 0x80619a30 <+768>:   movq   $0x0,0x8(%rsp)
> 
>  Were these instructions dumped from RAM or from the kernel ELF file?
> >>>
> >>> Probably not from RAM.  You can use 'info files' in gdb to see what
> >>> is handling the address range in question (core vs executable).  x/i
> >>> in ddb would have been the "real" truth.
> >>
> >> Yes, according to the output of files it looks like gdb would read
> >> that data from the text section of the kernel file.
> >>
> >> How about libkvm?  Would kvm_read read data from the core file?
> >
> > kvm_read should only access the vmcore, yes.
> >
> >> I've written the following small program (cut down dmesg.c, actually):
> >> https://people.freebsd.org/~avg/vmcore_read.c
> >>
> >> (kgdb) disassemble /r
> >> => 0x80619a1e <+750>:   48 c7 44 24 18 00 00 00 00  movq
> >> $0x0,0x18(%rsp)
> >>
> >> $ vmcore_read -N /boot/kernel.29/kernel -M /var/crash/vmcore.29
> >> 0x80619a1e 9
> >> 48 c7 44 24 18 00 00 00 00
> >>
> >> Seems like the code is intact.
> >>
> >> P.S.
> >> 1. To correct something I said earlier, the fault is #UD, not #GP.
> >> 2. The only "suspicious" activity at the time of the crash was the 
> >> execution of a bhyve VM.
> >
> > Was the crash in the guest or the host?  UD# seems even more bizarre.
> 
> It was the host.  This is bizarre indeed.  I can think only of two 
> possibilities:
>   - new CPU erratum
>   - corrupted data somehow getting into the instruction cache, but the 
> correct data being read during the crash dump (i.e. flaky memory)

Or perhaps a missing memory sync operation somewhere

> 
> --
> Andriy Gapon
> ___
> freebsd-hack...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Dag-Erling Smørgrav]

Julian Elischer  writes:
> The inclusion of the HPN patches meant that we could drop a custom
> unsupported HPN enabled ssh from our build process.  It makes ssh
> actually usable.

Define "usable".  Does it actually make a measurable difference with the
latest OpenSSH?  And if HPN is so important to you, is there a reason
why you can't use the port?

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Wake on LAN broken (probably between r290542 - r290606)?

[David Wolfskill]

My build machine ("freebeast") spends most of the time powered off.

One of my "always on" machines has a crontab entry for 23:47 to use
/usr/local/bin/wol (from ports/net/wol) to wake it up in time to do some
periodinc "daily" things, update its local mirror of the SVN repos, and
update it ports working copy; after I've updated stable/10 & head on it,
I set it to boot from the stable/10 slice & power it off -- and the
cycle repeats.

At least, that's what happened with this machine's predecessor for
several years, and with this one since its deployment several months
ago, until yesterday morning.

Yesterday morning, the machine did not power on; I figured someone had
managed to manually power it off (vs. "shutdown -p"), took evasive
action, and resumed normal operations.

Upon a recurrence this morning -- and after the evasive action &
resumption of normal operations, I decided to test a bit.  The machine
was last running:

FreeBSD 11.0-CURRENT #1897  r290667M/290668:1100089: Wed Nov 11 04:45:58 PST 
2015 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

I manually ran the /sur/local/bin/wol command... and Nothing Happened.

Went over to the machine; no lights.  Manualy turned it on (booting

FreeBSD 10.2-STABLE #1851  r290668M/290668:1002501: Wed Nov 11 04:20:05 PST 
2015 r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/GENERIC  amd64

-- just to be clear); once it came up, "shutdown -p now".  After seeing

...
acpi0: Powering system off

on serial console, re-issued /usr/local/bin/wol; machine came right up.

OK.  So /usr/local/bin/wol itself seems to be working, and freebeast's
hardware also seems OK.

Checking the log of builds for head on that machine, the last several
entries are:

FreeBSD 11.0-CURRENT #1892  r290439M/290439:1100086: Fri Nov  6 05:12:44 PST 
2015 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64
FreeBSD 11.0-CURRENT #1893  r290486M/290488:1100087: Sat Nov  7 07:48:26 PST 
2015 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64
FreeBSD 11.0-CURRENT #1894  r290542M/290542:1100089: Sun Nov  8 06:19:02 PST 
2015 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64
FreeBSD 11.0-CURRENT #1895  r290606M/290609:1100089: Mon Nov  9 04:44:14 PST 
2015 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64
FreeBSD 11.0-CURRENT #1896  r290647M/290647:1100089: Tue Nov 10 04:37:17 PST 
2015 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64
FreeBSD 11.0-CURRENT #1897  r290667M/290668:1100089: Wed Nov 11 04:45:58 PST 
2015 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

and since I'm pretty sure I would have recalled had the "wake on
LAN" failed on Monday (and I don't recall that), it seems likely that
some change made that day (thus, a commit between r290542 - r290606)
is what would have done it.

But a quick perusal of
 doesn't show
anything especially like a "smoking gun" -- to me, anyway.

Can anyone else confirm or refute my observations?  Or suggest a
hint?  I'll try narrowing it down myself, but I need to do it during
times I'm at home (so I can manually power the machine back up when
it fails to respond to WoL), so it may be a few days before I can
accomplish much that way.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: FYI: SVN to GIT converter currently broken, github is falling behind

[Eggert, Lars]

Hi,

I just got this error when fetching from remote; related?

[elars@laurel: ~/src] git fetch --all
Fetching origin
Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
Fetching upstream
remote: Counting objects: 557, done.
remote: Compressing objects: 100% (543/543), done.
remote: Total 557 (delta 213), reused 2 (delta 2), pack-reused 0
Receiving objects: 100% (557/557), 1.15 MiB | 433.00 KiB/s, done.
Resolving deltas: 100% (213/213), completed with 2 local objects.
From github.com:/freebsd/freebsd
   b4eb11a..3eb0ea4  master -> upstream/master
   f147893..9c319c0  stable/10  -> upstream/stable/10
   e901edd..b3c9fd2  stable/8   -> upstream/stable/8
   81ab2b1..2fc7a9a  stable/9   -> upstream/stable/9
   c2c933c..cc76737  svn_head   -> upstream/svn_head
Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
error: The last gc run reported the following. Please correct the root cause
and remove .git/gc.log.
Automatic cleanup will not be performed until the file is removed.

fatal: bad object refs/remotes/origin/HEAD
error: failed to run repack

Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
error: The last gc run reported the following. Please correct the root cause
and remove .git/gc.log.
Automatic cleanup will not be performed until the file is removed.

fatal: bad object refs/remotes/origin/HEAD
error: failed to run repack

Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: OpenSSH HPN

[Jan Bramkamp]

On 11/11/15 09:27, Ben Woods wrote:

On Wednesday, 11 November 2015, John-Mark Gurney  wrote:


Ben Woods wrote this message on Wed, Nov 11, 2015 at 15:40 +0800:

I have to agree that there are cases when the NONE cipher makes sense,

and

it is up to the end user to make sure they know what they are doing.

Personally I have used it at home to backup my old FreeBSD server (which
does not have AESNI) over a dedicated network connection to a backup

server

using rsync/ssh. Since it was not possible for anyone else to be on that
local network, and the server was so old it didn't have AESNI and would
soon be retired, using the NONE cipher sped up the transfer

significantly.

If you have a trusted network, why not just use nc?



Honest answer: ignorance of how I can use netcat together with rsync.


Sounds like you're looking for rsyncd instead of rsync over ssh (minus 
encryption).

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Jenkins build is back to normal : Build-UFS-image #2714

[jenkins-admin]

See 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Build failed in Jenkins: Build-UFS-image #2716

[jenkins-admin]

See 

--
Started by upstream project "Build_Image_and_Run_Tests_in_Bhyve_HEAD" build 
number 1757
originally caused by:
 Started by upstream project "FreeBSD_HEAD" build number 3515
 originally caused by:
  Started by an SCM change
Building remotely on jenkins-10.freebsd.org (FreeBSD-10)No JDK named ?null? 
found
 in workspace 
No JDK named ?null? found
No JDK named ?null? found
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/freebsd/freebsd-ci # 
 > timeout=10
Fetching upstream changes from https://github.com/freebsd/freebsd-ci
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > https://github.com/freebsd/freebsd-ci +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 65a323ece2701c4a650ed241aea8bdecfaf56ea9 
(refs/remotes/origin/master)
No JDK named ?null? found
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 65a323ece2701c4a650ed241aea8bdecfaf56ea9
 > git rev-list 65a323ece2701c4a650ed241aea8bdecfaf56ea9 # timeout=10
No JDK named ?null? found
[Build-UFS-image] $ /bin/sh -xe /tmp/hudson8410732282191817668.sh
+ freebsd-ci/scripts/build/build-ufs-image.sh
+ [ -z  ]
+ [ -z /builds/FreeBSD_HEAD ]
+ [ -z '' ]
+ export MAKEOBJDIRPREFIX=/builds/FreeBSD_HEAD/obj
+ [ -z '' ]
+ basename /builds/FreeBSD_HEAD
+ 
PACKAGE_ROOT=
+ [ -z '' ]
+ basename /builds/FreeBSD_HEAD
+ 
IMAGE_ROOT=
+ [ -n '' ]
+ [ -z /builds/FreeBSD_HEAD/obj ]
+ cd /builds/FreeBSD_HEAD
+ [ -z '' ]
+ [ -f /builds/FreeBSD_HEAD/make.conf ]
+ __MAKE_CONF=/builds/FreeBSD_HEAD/make.conf
+ sudo rm -fr 

rm: 
:
 Operation not permitted
rm: 
: 
Directory not empty
rm: : 
Directory not empty
Build step 'Execute shell' marked build as failure
No JDK named ?null? found
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD_HEAD-tests - Build #1682 - Still Unstable

[jenkins-admin]

FreeBSD_HEAD-tests - Build #1682 - Still Unstable:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1682/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1682/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD-tests/1682/console

Change summaries:

No changes


The failed test cases:

5 tests failed.
FAILED:  bin.sh.builtins.functional_test.case7

Error Message:
atf-check failed; see the output of the test for details

FAILED:  bin.sh.builtins.functional_test.locale1

Error Message:
atf-check failed; see the output of the test for details

FAILED:  lib.libc.locale.c16rtomb_test.c16rtomb_test

Error Message:
Premature exit; test case received signal 11 (core dumped)

FAILED:  lib.libc.locale.mbrtoc16_test.mbrtoc16_test

Error Message:
Premature exit; test case received signal 11 (core dumped)

FAILED:  
lib.libc.stdio.printfloat_test.thousands_separator_and_other_locale_tests

Error Message:
printf("%'.4f", 12345678.0625) ==> [1,23,45,678.0625], expected 
[123,456,78.0625]<>

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

kereros telnet/rlogin/etc. (was Re: OpenSSH HPN)

[Benjamin Kaduk]

On Wed, 11 Nov 2015, Daniel Kalchev wrote:

>
> Perhaps similar level of security could be achieved by “the old tools”
> if they were by default compiled with Kerberos. Although, this still
> requires building additional infrastructure.

The kerberized versions of the old tools are basically unsupported
upstream at this point.  Telnet is actively insecure, being limited to
single-DES; rlogin may be somewhat better but it's still not looking very
good.  ssh is better because it speaks GSS-API instead of raw kerberos,
and can thus keeps up with newer crypto automatically.

When I was working at MIT, I considered making a final release of the
krb5-appl distribution, so as to include in the release announcement that
they were not going to be supported further, but could not even bring
myself to do that.  They are not in Debian anymore, and I expect them to
dwindle from other distributions, too.

Let the "old tools" grow old and retire.

-Ben
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Slawa Olhovchenkov]

On Wed, Nov 11, 2015 at 10:18:08AM -0800, Bryan Drewery wrote:

> On 11/11/2015 10:13 AM, Slawa Olhovchenkov wrote:
> > On Wed, Nov 11, 2015 at 05:51:25PM +0100, Dag-Erling Smørgrav wrote:
> > 
> >> Bryan Drewery  writes:
> >>> Another thing that I did with the port was restore the tcpwrapper
> >>> support that upstream removed. Again, if we decide it is not worth
> >>> keeping in base I will remove it as default in the port.
> >>
> >> I want to keep tcpwrapper support - it is another reason why I still
> >> haven't upgraded OpenSSH, but to the best of my knowledge, it is far
> >> less intrusive than HPN.
> > 
> > Can you explain what is problem?
> > I am see openssh in base and openssh in ports (more recent version)
> > with same functionaly patches.
> > You talk about trouble to upgrade. What is root?
> > openssh in base have different vendor and/or license?
> > Or something else?
> > 
> > PS: As I today know, kerberos heimdal is practicaly dead as opensource
> > project. Have FreeBSD planed switch to MIT Kerberos?
> > I am know about security/krb5.
> > 
> 
> IMHO the problem comes down to time. Patching an upstream project
> increases maintenance cost for upgrading it. Every patch adds up. When
> you become busy and don't have time to pay attention to every little
> change made in a release, hearing 'removed tcpwrappers support' or
> 'refactored the code  for libssh usage' makes it sound like 1 more
> thing you must deal with to upgrade that code base and more effort to
> validate that your patches are right. We obviously don't want to just
> drop in the latest code and throw it out there as broken. SSH is quite
> critical and we want to ensure our changes are still right, and that
> doing something like adding tcpwrappers back in won't introduce some
> security bug that upstream was coy about.

Some for as ports version?
Or ports version different?
Or port mantainer have more time (this is not to blame for DES)?
I am just don't know what is different between port ssh and base ssh.
We need ssh 6.x in base, not 7.x as in port (why?) and this is need
independed work on pathes?
I am missing somehow commonplace for others.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Bryan Drewery]

On 11/11/2015 3:56 PM, Slawa Olhovchenkov wrote:
> On Wed, Nov 11, 2015 at 10:18:08AM -0800, Bryan Drewery wrote:
> 
>> On 11/11/2015 10:13 AM, Slawa Olhovchenkov wrote:
>>> On Wed, Nov 11, 2015 at 05:51:25PM +0100, Dag-Erling Smørgrav wrote:
>>>
 Bryan Drewery  writes:
> Another thing that I did with the port was restore the tcpwrapper
> support that upstream removed. Again, if we decide it is not worth
> keeping in base I will remove it as default in the port.

 I want to keep tcpwrapper support - it is another reason why I still
 haven't upgraded OpenSSH, but to the best of my knowledge, it is far
 less intrusive than HPN.
>>>
>>> Can you explain what is problem?
>>> I am see openssh in base and openssh in ports (more recent version)
>>> with same functionaly patches.
>>> You talk about trouble to upgrade. What is root?
>>> openssh in base have different vendor and/or license?
>>> Or something else?
>>>
>>> PS: As I today know, kerberos heimdal is practicaly dead as opensource
>>> project. Have FreeBSD planed switch to MIT Kerberos?
>>> I am know about security/krb5.
>>>
>>
>> IMHO the problem comes down to time. Patching an upstream project
>> increases maintenance cost for upgrading it. Every patch adds up. When
>> you become busy and don't have time to pay attention to every little
>> change made in a release, hearing 'removed tcpwrappers support' or
>> 'refactored the code  for libssh usage' makes it sound like 1 more
>> thing you must deal with to upgrade that code base and more effort to
>> validate that your patches are right. We obviously don't want to just
>> drop in the latest code and throw it out there as broken. SSH is quite
>> critical and we want to ensure our changes are still right, and that
>> doing something like adding tcpwrappers back in won't introduce some
>> security bug that upstream was coy about.
> 
> Some for as ports version?
> Or ports version different?
> Or port mantainer have more time (this is not to blame for DES)?
> I am just don't know what is different between port ssh and base ssh.
> We need ssh 6.x in base, not 7.x as in port (why?) and this is need
> independed work on pathes?
> I am missing somehow commonplace for others.
> 

I am the ports maintainer. That was my opinion on why OpenSSH falls
behind. There is no real difference between the base and port version
except that the port version has some more optional patches, and is
easier to push updates for through ports and packages, rather than an
Errata through freebsd-update or a full release to get to the latest
OpenSSH version.

There have been many times where the base version was more up-to-date
than the port as well due to the lack of a maintainer or the previously
mentioned patch blockers.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: OpenSSH HPN

[Slawa Olhovchenkov]

On Wed, Nov 11, 2015 at 03:58:35PM -0800, Bryan Drewery wrote:

> > Some for as ports version?
> > Or ports version different?
> > Or port mantainer have more time (this is not to blame for DES)?
> > I am just don't know what is different between port ssh and base ssh.
> > We need ssh 6.x in base, not 7.x as in port (why?) and this is need
> > independed work on pathes?
> > I am missing somehow commonplace for others.
> > 
> 
> I am the ports maintainer. That was my opinion on why OpenSSH falls
> behind. There is no real difference between the base and port version
> except that the port version has some more optional patches, and is
> easier to push updates for through ports and packages, rather than an
> Errata through freebsd-update or a full release to get to the latest
> OpenSSH version.

This impact only to deploy, not to patch, right?
Or bugs found around NPH/NONE patches?

> There have been many times where the base version was more up-to-date
> than the port as well due to the lack of a maintainer or the previously
> mentioned patch blockers.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Slawa Olhovchenkov]

On Wed, Nov 11, 2015 at 01:32:27PM -0800, Bryan Drewery wrote:

> On 11/10/2015 1:42 AM, Dag-Erling Smørgrav wrote:
> >  I would also like to remove the NONE cipher
> > patch, which is also available in the port (off by default, just like in
> > base).
> 
> Fun fact, it's been broken in the port for several months with no
> complaints. It was just reported and fixed upstream in the last day and
> I wrote in a similar fix in the port. That speaks a lot about its usage
> in the port currently.

I am try using NPH/NONE with base ssh and confused: don't see
performance rise, too complex to enable and too complex for use.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Bryan Drewery]

On 11/11/15 4:05 PM, Slawa Olhovchenkov wrote:
> On Wed, Nov 11, 2015 at 03:58:35PM -0800, Bryan Drewery wrote:
> 
>>> Some for as ports version?
>>> Or ports version different?
>>> Or port mantainer have more time (this is not to blame for DES)?
>>> I am just don't know what is different between port ssh and base ssh.
>>> We need ssh 6.x in base, not 7.x as in port (why?) and this is need
>>> independed work on pathes?
>>> I am missing somehow commonplace for others.
>>>
>>
>> I am the ports maintainer. That was my opinion on why OpenSSH falls
>> behind. There is no real difference between the base and port version
>> except that the port version has some more optional patches, and is
>> easier to push updates for through ports and packages, rather than an
>> Errata through freebsd-update or a full release to get to the latest
>> OpenSSH version.
> 
> This impact only to deploy, not to patch, right?

It's harder to maintain the port version due to how the patches are
applied and generated. That's only my problem though.

> Or bugs found around NPH/NONE patches?
> 
>> There have been many times where the base version was more up-to-date
>> than the port as well due to the lack of a maintainer or the previously
>> mentioned patch blockers.


-- 
Regards,
Bryan Drewery
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Roger Marquis]

On Wed, 11 Nov 2015, Dag-Erling Sm?rgrav wrote:

I want to keep tcpwrapper support - it is another reason why I still
haven't upgraded OpenSSH, but to the best of my knowledge, it is far
less intrusive than HPN.


There's also inetd's tcpwrapper support if you call sshd from inetd for
D/DOS protection.  Inetd and its rate-limiting flags are strongly
recommended for security-minded systems.

Starting sshd from rc.d should never have been made the default, IMO, as
keygen delays are rarely relevant and weren't even back in the days of
300MHz CPUs (18 years ago).  The only reason inetd is not more widely
used today is that many sysadmins aren't familiar with it.

Roger Marquis
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[John-Mark Gurney]

Ben Woods wrote this message on Wed, Nov 11, 2015 at 16:27 +0800:
> On Wednesday, 11 November 2015, John-Mark Gurney  wrote:
> 
> > Ben Woods wrote this message on Wed, Nov 11, 2015 at 15:40 +0800:
> > > I have to agree that there are cases when the NONE cipher makes sense,
> > and
> > > it is up to the end user to make sure they know what they are doing.
> > >
> > > Personally I have used it at home to backup my old FreeBSD server (which
> > > does not have AESNI) over a dedicated network connection to a backup
> > server
> > > using rsync/ssh. Since it was not possible for anyone else to be on that
> > > local network, and the server was so old it didn't have AESNI and would
> > > soon be retired, using the NONE cipher sped up the transfer
> > significantly.
> >
> > If you have a trusted network, why not just use nc?
> 
> Honest answer: ignorance of how I can use netcat together with rsync.

A quick google of rsync nc, turned up method 2 & 4 from:
https://rsync.samba.org/firewall.html

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Slawa Olhovchenkov]

On Wed, Nov 11, 2015 at 07:18:31PM +0100, Dag-Erling Smørgrav wrote:

> Slawa Olhovchenkov  writes:
> > Can you explain what is problem?
> 
> Radical suggestion: read the first email in the thread.

I am read and don't understund (you talk about trouble of maintaining
the HPN patches).
I see patched version in ports. This version maintaining.
What is problem? Differnt openssh? Quality of patches?
Different branches?
ports branch is worse (by some reaason) base branch?

> > PS: As I today know, kerberos heimdal is practicaly dead as opensource
> > project. Have FreeBSD planed switch to MIT Kerberos?  I am know about
> > security/krb5.
> 
> We switched from MIT to Heimdal at some point in the past for some
> reason I don't remember.  MIT and Heimdal are *not* interchangeable at

I think because MIT stop development in the past.

> the source or binary level, so switching back is not trivial.

I am know about this.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[John-Mark Gurney]

Daniel Kalchev wrote this message on Wed, Nov 11, 2015 at 17:49 +0200:
> It is my understanding, that using the NONE cypher is not identical to using 
> ???the old tools??? (rsh/rlogin/rcp).
> 
> When ssh uses the NONE cypher, credentials and authorization are still 
> encrypted and verified. Only the actual data payload is not encrypted.

Except the point is that you ALREADY trust your network, so you don't
need to encrypt the credentials and authorizations, otherwise, why are
you running unencrypted payloads?

In fact, if you aren't running at least a MAC, or a final verify, and
you're transfering large amounts of data (multiple gigabytes), the data
can and will likely be corrupted...

See:
http://noahdavids.org/self_published/CRC_and_checksum.html

Having not used the NONE cipher, I don't know if the MAC is also
removed or not...  Either way, the MAC is still the long poll when
it comes to encryption w/ AES-NI...

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Brooks Davis]

On Tue, Nov 10, 2015 at 04:40:42PM -0800, Bryan Drewery wrote:
> On 11/10/15 1:42 AM, Dag-Erling Sm??rgrav wrote:
> > Some of you may have noticed that OpenSSH in base is lagging far behind
> > the upstream code.
> > 
> > The main reason for this is the burden of maintaining the HPN patches.
> > They are extensive, very intrusive, and touch parts of the OpenSSH code
> > that change significantly in every release.  Since they are not
> > regularly updated, I have to choose between trying to resolve the
> > conflicts myself (hoping I don't break anything) or waiting for them to
> > catch up and then figuring out how to apply the new version.
> > 
> > Therefore, I would like to remove the HPN patches from base and refer
> > anyone who really needs them to the openssh-portable port, which has
> > them as a default option.  I would also like to remove the NONE cipher
> > patch, which is also available in the port (off by default, just like in
> > base).
> 
> I had this same problem as well, but have since reworked the HPN patch
> for ports to be more easily maintained.  I've considered offering or
> just updating the base SSH, but have not since we have random changes in
> the HPN functionality in base that would be lost.  We for some reason
> decided we were going to maintain our own version and not even upstream
> the changes to the HPN authors which has contributed to this situation.

We had ever intention of upstreaming our cleaned up HPN patches and some
interest from OpenSSH devs to take the window scaling portion of the
patch upstream, but other things intruded and we never found time to 
complete that work.  I think both the window scaling and NONE cipher
changes are useful, but do not have time to do anything with them.  I'm 
fine with them being removed from base and replaced or just dropped if
they are in the way of progress.

-- Brooks


signature.asc
Description: PGP signature

Re: Build failed in Jenkins: Build-UFS-image #2712

[Bryan Drewery]

On 11/11/2015 12:07 PM, jenkins-ad...@freebsd.org wrote:
> See 
> 
> --
> Started by upstream project "Build_Image_and_Run_Tests_in_Bhyve_HEAD" build 
> number 1754
> originally caused by:
>  Started by upstream project "FreeBSD_HEAD" build number 3512
>  originally caused by:
>   Started by an SCM change
> Building remotely on jenkins-10.freebsd.org (FreeBSD-10)No JDK named ?null? 
> found
>  in workspace 
> No JDK named ?null? found
> No JDK named ?null? found
>  > git rev-parse --is-inside-work-tree # timeout=10
> Fetching changes from the remote Git repository
>  > git config remote.origin.url https://github.com/freebsd/freebsd-ci # 
> timeout=10
> Fetching upstream changes from https://github.com/freebsd/freebsd-ci
>  > git --version # timeout=10
>  > git -c core.askpass=true fetch --tags --progress 
> https://github.com/freebsd/freebsd-ci +refs/heads/*:refs/remotes/origin/*
>  > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
>  > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
> Checking out Revision 65a323ece2701c4a650ed241aea8bdecfaf56ea9 
> (refs/remotes/origin/master)
> No JDK named ?null? found
>  > git config core.sparsecheckout # timeout=10
>  > git checkout -f 65a323ece2701c4a650ed241aea8bdecfaf56ea9
>  > git rev-list 65a323ece2701c4a650ed241aea8bdecfaf56ea9 # timeout=10
> No JDK named ?null? found
> [Build-UFS-image] $ /bin/sh -xe /tmp/hudson191250274494971404.sh
> + freebsd-ci/scripts/build/build-ufs-image.sh
> + [ -z  ]
> + [ -z /builds/FreeBSD_HEAD ]
> + [ -z '' ]
> + export MAKEOBJDIRPREFIX=/builds/FreeBSD_HEAD/obj
> + [ -z '' ]
> + basename /builds/FreeBSD_HEAD
> + 
> PACKAGE_ROOT=
> + [ -z '' ]
> + basename /builds/FreeBSD_HEAD
> + 
> IMAGE_ROOT=
> + [ -n '' ]
> + [ -z /builds/FreeBSD_HEAD/obj ]
> + cd /builds/FreeBSD_HEAD
> + [ -z '' ]
> + [ -f /builds/FreeBSD_HEAD/make.conf ]
> + __MAKE_CONF=/builds/FreeBSD_HEAD/make.conf
> + sudo rm -fr 
> 
> rm: 
> :
>  Operation not permitted
> rm: 
> :
>  Directory not empty
> rm: 
> : 
> Directory not empty
> Build step 'Execute shell' marked build as failure
> No JDK named ?null? found

I fixed the default install to properly set schg on /var/empty for PR
194189. This was a regression from the nmtree import during the 10.0
timeframe. So a chflags 0 is needed here now.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Build failed in Jenkins: Build-UFS-image #2712

[jenkins-admin]

See 

--
Started by upstream project "Build_Image_and_Run_Tests_in_Bhyve_HEAD" build 
number 1754
originally caused by:
 Started by upstream project "FreeBSD_HEAD" build number 3512
 originally caused by:
  Started by an SCM change
Building remotely on jenkins-10.freebsd.org (FreeBSD-10)No JDK named ?null? 
found
 in workspace 
No JDK named ?null? found
No JDK named ?null? found
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/freebsd/freebsd-ci # 
 > timeout=10
Fetching upstream changes from https://github.com/freebsd/freebsd-ci
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > https://github.com/freebsd/freebsd-ci +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 65a323ece2701c4a650ed241aea8bdecfaf56ea9 
(refs/remotes/origin/master)
No JDK named ?null? found
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 65a323ece2701c4a650ed241aea8bdecfaf56ea9
 > git rev-list 65a323ece2701c4a650ed241aea8bdecfaf56ea9 # timeout=10
No JDK named ?null? found
[Build-UFS-image] $ /bin/sh -xe /tmp/hudson191250274494971404.sh
+ freebsd-ci/scripts/build/build-ufs-image.sh
+ [ -z  ]
+ [ -z /builds/FreeBSD_HEAD ]
+ [ -z '' ]
+ export MAKEOBJDIRPREFIX=/builds/FreeBSD_HEAD/obj
+ [ -z '' ]
+ basename /builds/FreeBSD_HEAD
+ 
PACKAGE_ROOT=
+ [ -z '' ]
+ basename /builds/FreeBSD_HEAD
+ 
IMAGE_ROOT=
+ [ -n '' ]
+ [ -z /builds/FreeBSD_HEAD/obj ]
+ cd /builds/FreeBSD_HEAD
+ [ -z '' ]
+ [ -f /builds/FreeBSD_HEAD/make.conf ]
+ __MAKE_CONF=/builds/FreeBSD_HEAD/make.conf
+ sudo rm -fr 

rm: 
:
 Operation not permitted
rm: 
: 
Directory not empty
rm: : 
Directory not empty
Build step 'Execute shell' marked build as failure
No JDK named ?null? found
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[Bryan Drewery]

On 11/10/2015 1:42 AM, Dag-Erling Smørgrav wrote:
>  I would also like to remove the NONE cipher
> patch, which is also available in the port (off by default, just like in
> base).

Fun fact, it's been broken in the port for several months with no
complaints. It was just reported and fixed upstream in the last day and
I wrote in a similar fix in the port. That speaks a lot about its usage
in the port currently.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Build failed in Jenkins: Build-UFS-image #2713

[jenkins-admin]

See 

--
Started by upstream project "Build_Image_and_Run_Tests_in_Bhyve_HEAD" build 
number 1755
originally caused by:
 Started by upstream project "FreeBSD_HEAD" build number 3513
 originally caused by:
  Started by an SCM change
Building remotely on jenkins-10.freebsd.org (FreeBSD-10)No JDK named ?null? 
found
 in workspace 
No JDK named ?null? found
No JDK named ?null? found
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/freebsd/freebsd-ci # 
 > timeout=10
Fetching upstream changes from https://github.com/freebsd/freebsd-ci
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > https://github.com/freebsd/freebsd-ci +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 65a323ece2701c4a650ed241aea8bdecfaf56ea9 
(refs/remotes/origin/master)
No JDK named ?null? found
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 65a323ece2701c4a650ed241aea8bdecfaf56ea9
 > git rev-list 65a323ece2701c4a650ed241aea8bdecfaf56ea9 # timeout=10
No JDK named ?null? found
[Build-UFS-image] $ /bin/sh -xe /tmp/hudson4414984459389138688.sh
+ freebsd-ci/scripts/build/build-ufs-image.sh
+ [ -z  ]
+ [ -z /builds/FreeBSD_HEAD ]
+ [ -z '' ]
+ export MAKEOBJDIRPREFIX=/builds/FreeBSD_HEAD/obj
+ [ -z '' ]
+ basename /builds/FreeBSD_HEAD
+ 
PACKAGE_ROOT=
+ [ -z '' ]
+ basename /builds/FreeBSD_HEAD
+ 
IMAGE_ROOT=
+ [ -n '' ]
+ [ -z /builds/FreeBSD_HEAD/obj ]
+ cd /builds/FreeBSD_HEAD
+ [ -z '' ]
+ [ -f /builds/FreeBSD_HEAD/make.conf ]
+ __MAKE_CONF=/builds/FreeBSD_HEAD/make.conf
+ sudo rm -fr 

rm: 
:
 Operation not permitted
rm: 
: 
Directory not empty
rm: : 
Directory not empty
Build step 'Execute shell' marked build as failure
No JDK named ?null? found
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenSSH HPN

[John-Mark Gurney]

Ben Woods wrote this message on Wed, Nov 11, 2015 at 15:40 +0800:
> On Wednesday, 11 November 2015, Bryan Drewery  wrote:
> 
> > On 11/10/15 9:52 AM, John-Mark Gurney wrote:
> > > My vote is to remove the HPN patches.  First, the NONE cipher made more
> > > sense back when we didn't have AES-NI widely available, and you were
> > > seriously limited by it's performance.  Now we have both aes-gcm and
> > > chacha-poly which it's performance should be more than acceptable for
> > > today's uses (i.e. cipher performance is 2GB/sec+).
> >
> > AES-NI doesn't help the absurdity of double-encrypting when using scp or
> > rsync/ssh over an encrypted VPN, which is where NONE makes sense to use
> > for me.
> 
> I have to agree that there are cases when the NONE cipher makes sense, and
> it is up to the end user to make sure they know what they are doing.
> 
> Personally I have used it at home to backup my old FreeBSD server (which
> does not have AESNI) over a dedicated network connection to a backup server
> using rsync/ssh. Since it was not possible for anyone else to be on that
> local network, and the server was so old it didn't have AESNI and would
> soon be retired, using the NONE cipher sped up the transfer significantly.

If you have a trusted network, why not just use nc?

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: strange kernel crash

[Andriy Gapon]

On 10/11/2015 20:42, John Baldwin wrote:
> On Tuesday, November 10, 2015 10:48:08 AM Andriy Gapon wrote:
>> On 09/11/2015 22:16, John Baldwin wrote:
>>> On Friday, November 06, 2015 07:02:59 PM Hans Petter Selasky wrote:
 On 11/06/15 12:20, Andriy Gapon wrote:
> Now the strange part:
>
> 0x80619a18 <+744>:   jne0x80619a61 
> <__mtx_lock_flags+817>
> 0x80619a1a <+746>:   mov%rbx,(%rsp)
> => 0x80619a1e <+750>:   movq   $0x0,0x18(%rsp)
> 0x80619a27 <+759>:   movq   $0x0,0x10(%rsp)
> 0x80619a30 <+768>:   movq   $0x0,0x8(%rsp)

 Were these instructions dumped from RAM or from the kernel ELF file?
>>>
>>> Probably not from RAM.  You can use 'info files' in gdb to see what is
>>> handling the address range in question (core vs executable).  x/i in ddb
>>> would have been the "real" truth.
>>
>> Yes, according to the output of files it looks like gdb would read that data
>> from the text section of the kernel file.
>>
>> How about libkvm?  Would kvm_read read data from the core file?
> 
> kvm_read should only access the vmcore, yes.
> 
>> I've written the following small program (cut down dmesg.c, actually):
>> https://people.freebsd.org/~avg/vmcore_read.c
>>
>> (kgdb) disassemble /r
>> => 0x80619a1e <+750>:   48 c7 44 24 18 00 00 00 00  movq
>> $0x0,0x18(%rsp)
>>
>> $ vmcore_read -N /boot/kernel.29/kernel -M /var/crash/vmcore.29 
>> 0x80619a1e 9
>> 48 c7 44 24 18 00 00 00 00
>>
>> Seems like the code is intact.
>>
>> P.S.
>> 1. To correct something I said earlier, the fault is #UD, not #GP.
>> 2. The only "suspicious" activity at the time of the crash was the execution 
>> of
>> a bhyve VM.
> 
> Was the crash in the guest or the host?  UD# seems even more bizarre.

It was the host.  This is bizarre indeed.  I can think only of two 
possibilities:
- new CPU erratum
- corrupted data somehow getting into the instruction cache, but the correct
data being read during the crash dump (i.e. flaky memory)

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"