DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Installation and Upgrading

OpenBSD Installation and Upgrading Installing and upgrading OpenBSD.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 13th March 2016
jjstorm jjstorm is offline
Package Pilot
 
Join Date: Nov 2014
Location: Buenos Aires, AR
Posts: 144
Default 011: SECURITY FIX: March 10, 2016

I just applied this patch by following the instructions on the patch itself, and NOT by using CVS to update the source tree. That is o.k. Right? I follow 5.8 -stable.
Reply With Quote
  #2   (View Single Post)  
Old 13th March 2016
shep shep is offline
Real Name: Scott
Arp Constable
 
Join Date: May 2008
Location: Dry and Dusty
Posts: 1,349
Default

I'm not aware of what you had prior to applying the 011 patch, but the process essentially replaces the existing ssh code and should be OK.

My guess is that your trying different options (cvs, patches/m:tier, openup) in order to follow stable. You have the most control using cvs while openup is the least time consuming.
Reply With Quote
  #3   (View Single Post)  
Old 13th March 2016
jjstorm jjstorm is offline
Package Pilot
 
Join Date: Nov 2014
Location: Buenos Aires, AR
Posts: 144
Default

Quote:
Originally Posted by shep View Post
I'm not aware of what you had prior to applying the 011 patch, but the process essentially replaces the existing ssh code and should be OK.

My guess is that your trying different options (cvs, patches/m:tier, openup) in order to follow stable. You have the most control using cvs while openup is the least time consuming.
Prior to applying this patch, I had been updating my source tree by downloading it from cvs, and then recompiling it.

I remember reading somewhere in the faq, that you can mix and match. That is, you don't always have to update your source tree from cvs to apply a patch.

So since I applied the patch by following the instructions, there is nothing else for me to do right?
Reply With Quote
  #4   (View Single Post)  
Old 13th March 2016
e1-531g e1-531g is offline
ISO Quartermaster
 
Join Date: Mar 2014
Posts: 587
Default

I don't think mixing update methods is good.
I would stick to one: cvs, following stable or manually applying patches by hand (AFAIK there are not all patches, but only security fixes).

If somethings is wrong, I think that cvs is likely to report conflict.
Reply With Quote
  #5   (View Single Post)  
Old 13th March 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,189
Default

To be as clear as possible, errata patches are NOT -stable. They are included in -stable, but -stable may have more updates than published errata.*

When you next update your -stable source tree, you may have no issues, or it is possible CVS will note either a local modification "M" or a conflict "C". It will depend if there are any differences (such as white space) between the errata patch and the committed patch in the repository.

---

* Sometimes there are no -stable patches other than published errata. That is not the case for 5.8, which has more than 40 src repository modules with -stable commits at this writing.

Last edited by jggimi; 13th March 2016 at 02:54 PM. Reason: clarity
Reply With Quote
  #6   (View Single Post)  
Old 13th March 2016
ocicat ocicat is offline
Administrator
 
Join Date: Apr 2008
Posts: 3,307
Default

Quote:
Originally Posted by jggimi View Post
To be as clear as possible, errata patches are NOT -stable. They are included in -stable, but -stable may have more updates than published errata.*
I will add an additional verbalization.

Errata fixes are to be applied to -release, not -stable installations. -stable users should either update through CVS or subscribe to M:Tier.

...& what jggimi further states is correct. As an equation:
-release installation + all published errata <= up-to-date -stable installation
Reply With Quote
  #7   (View Single Post)  
Old 13th March 2016
jjstorm jjstorm is offline
Package Pilot
 
Join Date: Nov 2014
Location: Buenos Aires, AR
Posts: 144
Default

I updated the source tree, and compiled the kernel and userland. During downloading of the source, cvs warned about an ssh conflict, and there was another warning while compiling the userland, however, all seems to be well. I'll avoid doing this in the future.
Reply With Quote
  #8   (View Single Post)  
Old 13th March 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,189
Default

Quote:
Originally Posted by jjstorm View Post
...During downloading of the source, cvs warned about an ssh conflict...
To correct this, return to the ssh branch of your working directory, /usr/src/usr.bin/ssh. Issue $ cvs up from this branch of the working directory, and note which files are marked with "C" or "M".

Files marked "M" are deemed to have a local modification. Local modifications may be removed by issuing the CVS update command with the -C option to overwrite localy modified files: $ cvs up -C.

Files marked "C" are deemed to be in conflict: CVS perceives local modifications atop of pending commits, which it cannot resolve. This requires manual action by the admin. In this instance, that manual option should be moving (or deleting) the conflicting files, then issuing $ cvs up once again, to obtain the files as committed to the repository.
Quote:
...there was another warning while compiling the userland...
Without knowing its specific contents, I cannot give any guidance other than to recommend rebuilding -stable after you have confirmed you are using committed -stable source.
Reply With Quote
  #9   (View Single Post)  
Old 16th March 2016
jjstorm jjstorm is offline
Package Pilot
 
Join Date: Nov 2014
Location: Buenos Aires, AR
Posts: 144
Default

Quote:
Originally Posted by jggimi View Post
To correct this, return to the ssh branch of your working directory, /usr/src/usr.bin/ssh. Issue $ cvs up from this branch of the working directory, and note which files are marked with "C" or "M".

Files marked "M" are deemed to have a local modification. Local modifications may be removed by issuing the CVS update command with the -C option to overwrite localy modified files: $ cvs up -C.

Files marked "C" are deemed to be in conflict: CVS perceives local modifications atop of pending commits, which it cannot resolve. This requires manual action by the admin. In this instance, that manual option should be moving (or deleting) the conflicting files, then issuing $ cvs up once again, to obtain the files as committed to the repository.Without knowing its specific contents, I cannot give any guidance other than to recommend rebuilding -stable after you have confirmed you are using committed -stable source.

Below is what I did and the respond I received.

Code:
# cvs up
cvs server: Updating .
C session.c
cvs server: Updating lib
cvs server: Updating moduli-gen
cvs server: Updating scp
cvs server: Updating sftp
cvs server: Updating sftp-server
cvs server: Updating ssh
cvs server: Updating ssh-add
cvs server: Updating ssh-agent
cvs server: Updating ssh-keygen
cvs server: Updating ssh-keyscan
cvs server: Updating ssh-keysign
cvs server: Updating ssh-pkcs11-helper
cvs server: Updating sshd
I am not certain where to go from here. Do I need to insert the -rOPENBSD_5_8 tag into the $ cvs up -C command since I am following stable?

Also, once I do this, should I update my source normally and then recompile the source tree and userland?

Last edited by jjstorm; 16th March 2016 at 10:00 PM.
Reply With Quote
Old 17th March 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,189
Default

Quote:
Originally Posted by jjstorm View Post
Below is what I did and the respond I received.
This branch of your working directory tree currently contains neither conflicts nor local modifications.

All -stable commits include a revision to the RCS header in line 1 of every source file. The errata patches do not have this RCS revision. Check the first line of /usr/src/usr.bin/ssh/session.c, and note the revision number of the file. Below, I obtain three revisions of this file.

-release or -release + errata:
Code:
$ cvs get -r OPENBSD_5_8_BASE src/usr.bin/ssh/session.c
U src/usr.bin/ssh/session.c
$ head -1 src/usr.bin/ssh/session.c
/* $OpenBSD: session.c,v 1.278 2015/04/24 01:36:00 deraadt Exp $ */
$
-stable:
Code:
$ cvs get -r OPENBSD_5_8 src/usr.bin/ssh/session.c
U src/usr.bin/ssh/session.c
$ head -1 src/usr.bin/ssh/session.c
/* $OpenBSD: session.c,v 1.278.2.1 2016/03/10 11:54:22 djm Exp $ */
$
-current:
Code:
$ cvs get -A src/usr.bin/ssh/session.c
U src/usr.bin/ssh/session.c
$ head -1 src/usr.bin/ssh/session.c
/* $OpenBSD: session.c,v 1.282 2016/03/10 11:47:57 djm Exp $ */
$
Quote:
Do I need to insert the -rOPENBSD_5_8 tag into the $ cvs up -C command since I am following stable?
No, tags are "sticky." You can see them in any of the working directory branches and leaves, as each directory contains a CVS directory and within, you will see a Tag file.
Quote:
should I update my source normally and then recompile the source tree and userland?
It appears your source tree is now -stable, but you should check the applicable RCS headers as noted above to confirm. If it is now indeed -stable, you may rebuild it if you wish. It will take time, but will provide you with the assurance that your source matches your binary. In this instance, it appears to me that your deviation from standard practice has not caused any harm.
Reply With Quote
Old 17th March 2016
ocicat ocicat is offline
Administrator
 
Join Date: Apr 2008
Posts: 3,307
Default

Quote:
Originally Posted by jjstorm View Post
Do I need to insert the -rOPENBSD_5_8 tag into the $ cvs up -C command since I am following stable?
Studying Section 5.2 of the official FAQ can be your friend.

Reply With Quote
Old 17th March 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,189
Default

And there is a new patch 012 to 5.8 for IPv6 that was published yesterday.
  1. Those who build -stable from source may cvs up and rebuild per FAQ 5 and release(8).
  2. Those who patch -release may do so, following the instructions in the patch.
  3. Those who use M:Tier's stable services should follow their recommended procedures, which is liikely to be using their openup tool, per https://stable.mtier.org

Last edited by jggimi; 17th March 2016 at 12:24 PM. Reason: clarity
Reply With Quote
Old 17th March 2016
shep shep is offline
Real Name: Scott
Arp Constable
 
Join Date: May 2008
Location: Dry and Dusty
Posts: 1,349
Default

Quote:
Originally Posted by jggimi View Post
And there is a new patch 012 to 5.8 for IPv6 that was published yesterday.
  1. Those who use M:Tier's stable services should follow their recommended procedures, which is likely to be using their openup tool, per https://stable.mtier.org
M:tier's openup script, as normally used, automates the base security/bug fixes and available package fixes. It is also possible to update the base using pkg_add:

Quote:
Installing binpatches

Since binpatches will update parts of the base system, you have to manually install them for now. When an update is available for a binpatch you will be able to update it with pkg_add -u like a regular package.

Installing a binpatch works just like a regular package. So for example:

pkg_add binpatch58-amd64-sshd-1.0.tgz
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Are you at AsiaBSDcon 2016? ibara News 4 25th March 2016 05:42 PM
Misc. BSD/UNIX BSDCan 2016 CfP now open! ibara News 0 1st December 2015 10:42 PM
March BSD Magazine J65nko News 0 24th March 2014 11:49 PM
Firefox 4 to ship March 22nd drhowarddrfine News 12 24th March 2011 12:02 AM
OpenSSL Security Advisory [24 March 2010] J65nko News 0 29th March 2010 11:12 PM


All times are GMT. The time now is 09:14 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick