On Fri, 12 Oct 2018, Sebby, Brian A. wrote:

> Previous releases have included source RPMs that made it easier for us to 
> build RPMs to deploy to our Red Hat-based servers. 
> I was hoping it maybe had just not yet been released yet, but there still 
> isn’t a source RPM for 1.6.23.  It looks like one
> was built for 1.6.24.4, so I may just end up deploying that since we do not 
> use any of the backup utilities.  I know that
> support for RPMs from OpenAFS is something that’s been discussed for a long 
> time, but I hadn’t seen any official announcement
> (unless I missed it) that indicated that they would no longer be created.
> 
> For any other folks using Red Hat – what are you doing for deploying OpenAFS? 
>  Are there any repos out there equivalent to
> the Ubuntu PPA?

I've never managed to go from source tarball to clean RPMs. I found a wiki 
entry explaining how make a srpm, but it didn't work for me, at least for 
recent releases.

However, there is a wiki entry explaining how to build from a git 
checkout, and that worked once I had all the GNU autotools in place.  I'm 
sure this procedure does far more work than needed, but this is the brief 
summary of steps:

$ cd ~/projects/openafs/1.8.2
$ git clone git://git.openafs.org/openafs.git
$ cd openafs
$ git checkout openafs-stable-1_8_2
$ ./regen.sh
$ ./configure --enable-transarc-paths --enable-checking --enable-supergroups
$ make dist
$ make srpm
$ rpmbuild --rebuild -ba --define "_topdir `pwd`/rpmbuild" --with kauth 
packages/openafs-1.8.2-1.src.rpm
$ cd rpmbuild/x86_64/

   - copy the resulting RPMs to local distribution point.

This worked cleanly on RHEL6 and RHEL7

Richard

> Brian
> 
>  
> 
> --
> 
> Brian Sebby  ([email protected])  |  Information Technology Infrastructure
> 
> Phone: +1 630.252.9935        |  Business Information Services
> 
> Cell:  +1 630.921.4305        |  Argonne National Laboratory
> 
>  
> 
>  
> 
> From: <[email protected]> on behalf of Benjamin Kaduk 
> <[email protected]>
> Date: Tuesday, September 11, 2018 at 2:09 PM
> To: <[email protected]>
> Cc: <[email protected]>, <[email protected]>
> Subject: [OpenAFS] OpenAFS Security Releases 1.8.2, 1.6.23 available
> 
>  
> 
>  
> 
> The OpenAFS Guardians are happy to announce the availability of
> 
> Security Releases OpenAFS 1.8.2 and 1.6.23.
> 
> Source files can be accessed via the web at:
> 
>  
> 
>        https://www.openafs.org/release/openafs-1.8.2.html
> 
>        https://www.openafs.org/release/openafs-1.6.23.html
> 
>  
> 
> or via AFS at:
> 
>  
> 
>        UNIX: /afs/grand.central.org/software/openafs/1.8.2/
> 
>        UNC: \\afs\grand.central.org\software\openafs\1.8.2\
> 
>        UNIX: /afs/grand.central.org/software/openafs/1.6.23/
> 
>        UNC: \\afs\grand.central.org\software\openafs\1.6.23\
> 
>  
> 
> These releases include fixes for three security advisories,
> 
> OPENAFS-SA-2018-001, OPENAFS-SA-2018-002, and OPENAFS-SA-2018-003.
> 
>  
> 
> OPENAFS-SA-2018-001 only affects deployments that run the 'butc' utility
> 
> as part of the in-tree backup system, but is of high severity for
> 
> those sites which are affected -- an anonymous attacker could replace
> 
> entire volumes with attacker-controlled contents.
> 
>  
> 
> OPENAFS-SA-2018-002 is for information leakage over the network via
> 
> uninitialized RPC output variables.  A number of RPCs are affected,
> 
> some of which require the caller to be authenticated, but in some cases
> 
> hundreds of bytes of data can be leaked per call.  Of note is that
> 
> cache managers are also subject to (kernel) memory leakage via
> 
> AFSCB_ RPCs.
> 
>  
> 
> OPENAFS-SA-2018-003 is a denial of service whereby anonymous attackers
> 
> can cause server processes to consume large quantities of memory for
> 
> a sustained period of time.
> 
>  
> 
> Please see the release notes and security advisories for additional details.
> 
>  
> 
> The changes to fix OPENAFS-SA-2018-001 require behavior change in both
> 
> butc(8) and backup(8) to use authenticated connections; old and new
> 
> versions of these utilities will not interoperate absent specific
> 
> configuration of the new tool to use the old (insecure) behavior.
> 
> These changes also are expected to cause backup(8)'s interactive mode
> 
> to be limited to only butc connections requiring (or not requiring)
> 
> authentication within a given interactive session, based on the initial
> 
> arguments selected.
> 
>  
> 
> Bug reports should be filed to [email protected].
> 
>  
> 
> Benjamin Kaduk
> 
> for the OpenAFS Guardians
> 
>  
> 
> 
>

-----
Richard Brittain,  Research ITC
                    Information, Technology and Consulting,
                    37 Dewey Field Road, HB6219
                    Dartmouth College, Hanover NH 03755
[email protected] 603-646-2085
http://rc.dartmouth.edu/

Reply via email to