Bug#886806: intel-microcode: New version 20180108 published

2018-01-09 Thread Karl Kornel
Package: intel-microcode
Version: 3.20171215.1
Severity: grave
Tags: security

Hello!

In the ancient past (last week…), Mr. Holschuh mentioned, “I expect an official 
release from Intel soon, hopefully with updates for everything.”.

Well, it looks like there has been a release!  The data file version is 
20180108.

The microcode download page is 
https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File

--
A. Karl Kornel | System Administrator
Research Computing | Stanford University



Bug#828549: SLURM OpenSSL 1.1 issue - Patch to disable OpenSSL support until upstream fixes

2016-11-02 Thread Karl Kornel
Hi Mehdi,

That’s awesome!  Changing the code is definitely preferable, as long as the 
code works with older versions of MySQL.

To check this, I tried building SLURM in a Jessie COWbuilder installation.  In 
order to test, one dependency had to be changed in the control file: Change 
“default-libmysqlclient-dev” to “libmysqlclient-dev”.  The test took place with 
OpenSSL 1.0.1 (specifically, OpenSSL source package version 1.0.1t-1+deb8u3).

I also tried building for Ubuntu Xenial (again using COWbuilder), which has 
OpenSSL package version 1.0.2g-1ubuntu4.5.  This also required changing the 
control file, as with Jessie.

I did not test in Wheezy, because there are other dependency issues (like a 
minimum debhelper version) that would need to be changed.  I also did not test 
on Ubuntu Trusty.

Both builds were able to complete.  You can download the results here:

Debian Jessie (16.05.6-2~sbp81+1, for jessie-backports): 
https://stanford.box.com/s/tehux7vh57w75k9sfjjpt0s0sjiugor1
Ubuntu Xenial (16.05.6-2~sbp16.04+1, for xenial-backports: 
https://stanford.box.com/s/opnjc8ab5dqzrwwp3qi2rutvfa1mu51l

(I’ll keep each links working until the bug is fixed upstream)

“sbp” stands for “Stanford Backport”, since this isn’t an official backport.  
Each .tar.gz has all of the stuff you would need to upload to a repository of 
your own, so you can either install the .deb files manually, or you could use 
the .changes file to upload to a repository of your own.  The versions are 
numbered so that when Gennaro releases 16.05.6-2 (or something later), that 
will take precedence over the ones I built.

Unfortunately, I don’t think your patch would be able to work directly, because 
the quilt build process requires that the original code be untouched; all of 
the changes to source have to be Quilt patches.  So, I’ve taken your patch and 
converted it into a quilt patch!  I’m attaching to this email a Git commit 
patch that creates the quilt patch, and updates the patch series list.

So, here are the next steps that I would suggest:

* Mehdi, you should go to https://bugs.schedmd.com, create an account, open bug 
3226, and attach your patch (the original one you sent me).  I’m asking you to 
do it because you are the author, so you should get the credit for it.
* Anyone who wants to test on Jessie or Xenial can use one of the builds that I 
made.
* In the meantime, if Gennaro decides to go forward with your code, he could 
use the quilt patch I’ve attached here. 

Thanks much for the patch!

~ Karl 



0001-Add-support-for-OpenSSL-1.1.patch
Description: 0001-Add-support-for-OpenSSL-1.1.patch


Bug#828549: SLURM OpenSSL 1.1 issue - Patch to disable OpenSSL support until upstream fixes

2016-11-02 Thread Karl Kornel
forwarded 828549 https://bugs.schedmd.com/show_bug.cgi?id=3226
tags 828549 + patch
thanks

Hello!

It looks like even the latest SLURM Debian package, 16.05.6-1, still has this 
issue. I tested with OpenSSL package version 1.1.0b-2, building on a sid 
COWbuilder.

The issue is being tracked upstream at this URL:

https://bugs.schedmd.com/show_bug.cgi?id=3226

The bug was filed on Oct. 31, and acknowledged on Nov. 1.

SLURM only uses OpenSSL in one place: To create “job step credentials”.  
However, this is not the default: the default is to have MUNGE create those 
credentials.

Since OpenSSL is only used in one place, and that’s not even as the default, I 
have created a Quilt patch which removes OpenSSL from the build entirely.  
Unfortunately, it’s not enough to change how we run ./configure; if the 
configure script sees an OpenSSL installation, it will use it, so I have to 
completely remove the test for OpenSSL, as well as the Makefile.am file that 
would trigger the compilation of OpenSSL-using code.

The same Quilt patch also updates the configuration builder HTML, to remove the 
OpenSSL option.

Finally, I update the the control file, README files, and the init scripts 
(removing the OpenSSL-related checks).

All of these changes are in a series of two Git patch files, which are attached.

--
A. Karl Kornel | System Administrator
Research Computing | Stanford University
+1 (650) 736-9327



0002-Update-Debian-files-for-OpenSSL-removal.patch
Description: 0002-Update-Debian-files-for-OpenSSL-removal.patch


0001-Add-quilt-patch-to-disable-OpenSSL.patch
Description: 0001-Add-quilt-patch-to-disable-OpenSSL.patch