Upgrade Postfix to 2.11 and Squid to 3.5


#1

Postfix 2.11 and + need for support DANE
Squid 3.5 need for support SHA2 bumped certificate


(Filippo Carletti) #2

This is a “difficult” topic, that deserves a bit of discussion: please, share your thoughts.
As a general rule, NethServer tries to work with CentOS packages, usually not the latest version, as per policy from upstream.
We also get packages from epel.
Sometimes, we need a small patch that we try to push upstream.

At the same time, some packages are “critical” for new features and we need to build them ourselves.

Both postfix and squid are candidates, as is samba for AD support.

To use “our” packages, we need a wide base of testers, but we will never has as many testers as CentOS.

Another option would be to build NethServer over Fedora server, which uses software versions more current, but as a life cycle of only 6 months.


(Stéphane de Labrusse) #3

A release every 6 months but with 13 months of support

Edit : for a server distro it is a huge ressource consumer and useless…IMHO…centos7 is the target


(Filippo Carletti) #4

Thanks @stephdl, I agree with you.
I was hoping to involve more people here, I think that we need to move forward with squid. I have already evaluated the new peek and splice options, we could really benefit from those.

postifx is a bit harder, but we could need it to support a smarthost on ssl.
DANE is still not widely supported, but I’d like to have it sooner than later.


(Davide Principi) #5

Indeed I’d like downgrading the currently recompiled Postfix package to the official upstream version, if we could do without the kerberos client libraries for AD integration.


#6

I agree that the problem with Postfix support DANE is much smaller than the squid.
In contrast, the problem with the squid may be relatively early serious.

SHA1 that it will cease to be supported by 1 January 2017 all do we know about:


http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-authenticode-code-signing-and-timestamping.aspx
[Mozilla end of SHA1][1]https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms

But because of similar to studies for example here http://www.infoworld.com/article/2990831/security-management/sha-1-hashing-algorithm-could-succumb-to-75k-attack-researchers-say.html I think no longer SHA1 algorithm is supported unpleasant earlier https://blog.mozilla.org/security/2015/10/20/continuing-to-phase-out-sha-1-certificates (“However, in light of recent attacks on SHA-1, we are also considering the feasibility of having a cut-off date as early as July 1, 2016”)

So if you want NethServer to be considered safe is a need to move with the squid than longer not be supported SHA1 in the browsers.


(Filippo Carletti) #7

We began to disable sha-1 in 6.7, see http://dev.nethserver.org/issues/3246.
I will work on a newer squid version next week.
Issue: http://dev.nethserver.org/issues/3314


#8

With this message I am very pleased. Thank you so much.
Just to be sure. These are the command http://www.squid-cache.org/Doc/config/sslproxy_cert_sign_hash


(Stefano) #9

Please be aware that RH (and so Centos) will backport any kind of security issue/patch…

IMO, if the current squid release in Centos 6.X will need some patch, they’ll come from upstream…


(Filippo Carletti) #10

Interim update.
I’m using squid-3.5 on a test system, it’s working fine, but I still haven’t completed tests on ssl.
The problem I don’t know how to solve is that the update from squid-3.3 to 3.5 doesn’t succeed due to a cpio error. It’s related to changing symlinks to directories, it’s an open bug on fedora, I think I’l wait and see if they fix the problem (either in rpm or in squid).
A possible workaround is a manual remove of squid-3.3 followed by a new install of 3.5.
Interested users could follow the workaround and we could start using 3.5 on new installations of NethServer 7.


#11

hi @filippo_carletti, any news on squid 3.5 update?


(Filippo Carletti) #12

Bad news. :frowning:
The rpm package can’t be upgraded in place. As a workaround I upgraded to 3.4 first and then to 3.5. But this path can’t be used in production.

Apart from upgrade path, squid 3.5 works fine.
We could offer it as an option to be installed manually.
Any better ideas?


#13

honestly not :pensive:
i was hoping in some magic from a specfile guru :slight_smile:
btw, installed manually the 3.5 and seems to work well

for ns7 can we start directly from 3.5?