Download Openssl Debian
Alexander Rodriguez
Luciano Bello discovered that the random number generator in Debian'sopenssl package is predictable. This is caused by an incorrectDebian-specific change to the openssl package (CVE-2008-0166). As aresult, cryptographic key material may be guessable.
In addition to this critical change, two other vulnerabilities have beenfixed in the openssl package which were originally scheduled for releasewith the next etch point release: OpenSSL's DTLS (Datagram TLS,basically SSL over UDP) implementation did not actually implement theDTLS specification, but a potentially much weaker protocol, andcontained a vulnerability permitting arbitrary code execution(CVE-2007-4995). A side channel attack in the integer multiplicationroutines is also addressed (CVE-2007-3108).
Tonetheman (May 21, 2008 7:27 AM) First off I DO NOT see why Debian needs to change openssl in the first place. Perhaps I do not understand that part.
Then second, valgrid/purify is a tool. Blindly following the suggestions of this or any other source analyzer tool is NOT the business of anyone who is upstream of the real package developers. Sorry. If you do not understand something do not change it.
I have worked at places before with zealots that use Java source analyzers like a weapon. It is a joke and they are a joke.
Use you head. Think think think. Just because valgrind/purify says it does not make it right. Lint was the same way and so will every other source analysis tool.
Gábor (May 21, 2008 9:29 AM) Also let's not forget the reason for this patch: to silence some valgrind warning.
i think debian should not patch a package (especially such an important, central package) just because some code-checker tool showed some warnings.
if openssl would crash, or be unusable in some other way, then ok, do something about it. but just for a valgrind-warning? simply submitting the patch upstream would have been a much better solution.
Mark (May 22, 2008 12:13 PM) "Also let's not forget the reason for this patch: to silence some valgrind warning.
i think debian should not patch a package (especially such an important, central package) just because some code-checker tool showed some warnings."
The issue here wasn't warnings on OpenSSL, but that you got the warnings whenever you ran valgrind on software that used OpenSSL. This made it very hard to see any potential problems with your software because of the huge numbers of OpenSSL-related warnings.
That's also presumably why "If it helps with debugging" was interpreted as it being OK to use in production deployments - it's a production deployment of OpenSSL, possibly used to debug some client code.
I am running debian jessie on my server and recently upgraded to new nginx web server with http/2 support (nginx 1.10). As today, it works great and webserver is delivering content with http2 protocol.
I have read, that chrome is dropping NPN support and only allows ALPN after 15.5.2016. ALPN is extension, which requires openssl 1.0.2 installed, but on debian jessie is only openssl 1.0.1 (also on debian backports and another repositories, there is no openssl 1.0.2 version for this debian).
And there is the problem - i have upgraded from SPDY to http2 and in few days, i will have to turn off http2 and cannot use SPDY because this version of nignx have only http2. I have also read, that this version of debian will stuck with openssl 1.0.1 and only debian stretch will have openssl 1.0.2. But to release date there is almost year and chrome will be dropping support soon, so i do not want to loose the benefit of http2 protocol.
Is there any solution, how to install openssl 1.0.2 on this system, without building own build (bad maintenance) or waiting for backports repository to have it? I also don't want two versions of openssl on my system if one of them must be linked and maintained manually.
Update 2016/08/08: nginx in jessie-backports (version 1.9.10-1bpo8+3 was built against openssl >= 1.0.2. Getting ALPN working now if running jessie just requires the packages out of jessie-backports, no need anymore to pull packages out of stretch.
Original answer: Well, here goes my answer, according to the comments: In my opinion, there aren't that many ways to solve this as of today, 2016/05/09. Basically you've to try somehow to get a modern nginx into your system, compiled against >= openssl 1.0.2.
(I had set this in the general Apache config as well as in /etc/ssl/openssl.cf`, but since this was set at the virtualhost level, it was overriding that. All the other virtualhosts happened to be at level 0 already, and I just happened to be testing using the one virtualhost that was overridden to 1, naturally...)
i start installation and i have the error
yunohost : Conflicts: openssl (>= 1.1.1o-0) but 1.1.1w-0+deb11u1 is to be installed
E: Unable to correct problems, you have held broken packages.
Why? How can i fix it?
Can you please be more specific? What Linux distribution are you using? What command are you using to install openssl in your system (not in R)? Do you get any error message while installing the openssl system library?
Back in April 2006, a Debian user reported aproblem using the OpenSSL library with valgrind, a tool that can checkprograms for memory access problems. It was reporting that OpenSSL wasusing uninitialized memory in parts of the random number generator (RNG)code. Using memory before it is initialized to a known value is a wellknown way to create hard-to-find bugs, so it is not surprising that thevalgrind report caused some consternation.Debian hacker Kurt Roeckx tracked the problem down to what he thought weretwo offending lines of code and posted a question onthe openssl-dev mailing list:What I currently see as best option is to actually comment outthose 2 lines of code. But I have no idea what effect thisreally has on the RNG. The only effect I see is that the poolmight receive less entropy. But on the other hand, I'm not evensure how much entropy some unitialised data has.What do you people think about removing those 2 lines of code?
There were few responses, but they were not opposed to removing the lines,including one from UlfMöeller using an openssl.org email address: "If it helpswith debugging, I'm in favor of removing them." Unfortunately, aswas discovered recently, removing one of the two lines was harmless, theother essentially crippled the RNG so that OpenSSL-generated cryptographickeys were easy to predict. (For more technical details on the bug and what should be done to respond toit, see our article on thisweek's Security page.)
It turns out, atleast according to OpenSSL core team member Ben Laurie, that openssl-dev is not for discussingdevelopment of OpenSSL. That may be true in practice, but the OpenSSL support web page describesit as: "Discussions on development of the OpenSSL library. Not forapplication development questions!" In addition, the addresssuggested by Laurie (openssl-team-AT-openssl.org) does not appear in any ofthe OpenSSLdocumentation or web pages. If it wasn't the right place, it would seemthat the OpenSSL developers could have provided a helpful pointer to the right address, but that did not occur.
It probably was not clear that Roeckx was asking the questions in anofficial Debian capacity, nor that he was planning to change theDebian package based on the answer to his questions. As Laurie rightly points out, he shouldhave submitted a patch, proposing that it be accepted into the upstreamOpenSSL codebase. That probably would have garnered more attention, evenif it was only posted to openssl-dev. It seems very unlikely thatthe patch in question would have ever made it into an OpenSSL release.
I am trying to build and deploy a CPP application (written for a linux envirionment) on Toradex Apalis iMX8QM board with Torizoncore. I use visual studio 2019 as my development environment. My application uses openssl and zlib libraries. I get the following errors while building:
The container that starts running in the build environment is: arm64v8-debian-base_buster_2a0fe2f5-cc3f-4788-a3c9-58900e05f974_debug_sdk based on the image: arm64v8-debian-base_buster_2a0fe2f5-cc3f-4788-a3c9-58900e05f974_debug_sdk_image. (Listed from the commands docker ps and docker images respectively). I can step into the running container using the command docker exec -it CONTAINER ID /bin/bash and see that the build folder is created at location /home.
So I built a new image from the running container (using docker commit) with the libraries that I need (basically the arm64v8-debian-base_buster_debug_######_sdk container with the openssl and zlib libraries that I installed), and pushed this image into docker hub. Next thing, I changed the name of the image in C:\lokal\rudhi\torizonCPP\MyProject\appconfig_0\work\Dockerfile.debug to the name of the new image that I just pushed. Changing the Dockerfile does not seem to be the right solution as far as I understand, because it is still building a new debian-base_buster container in the build environment instead of a container from my newly built image.
f5d0e4f075