There's an interesting case for OpenSSL-3.0, we do test it, but we run it in "relaxed" mode, while Ubuntu 22.04 and Fedora run it in SECLEVEL=2 mode.
that will definitely change when "ubuntu-latest" become 22.04, but we should test it before вт, 18 окт. 2022 г. в 18:28, Илья Шипицин <chipits...@gmail.com>: > > > вт, 18 окт. 2022 г. в 17:40, William Lallemand <wlallem...@haproxy.com>: > >> On Tue, Oct 18, 2022 at 03:10:07PM +0500, Илья Шипицин wrote: >> > > Sorry I didn't see the first commit that introduced this behavior. >> I'm >> > > not sure we would want to replace the version automatically in the CI >> > > for OpenSSL. >> > > >> > >> > it was supposed behaviour for OPENSSL_VERSION=latest >> > >> >> Yes, that's exactly why I said that I missed the introduction of that >> change :-) >> >> > > Currently we are testing the stock OpenSSL of the ubuntu which is >> 1.1.1, >> > > the 1.0.2u and the "latest". The latest is currently a 3.0.x but once >> > > the 3.1.x is released we would still need the 3.0 branch. >> > > >> > >> > I think we should review our approach to "stock" and "latest" when >> > ubuntu-latest >> > will be 22.04 (it is shipped with 3.0.X) >> > >> > I'll have a look at your point as well >> >> >> Sure, that's not urgent, we will need to add a 1.1.1 separately in this >> case. >> >> > > I think we need something to test the latest release of a branch, and >> > > not the latest version of all branches. Maybe we could specify "3.0.x" >> > > to get the latest 3.0? >> > > >> > >> > maybe-maybe-maybe. >> > >> > we can introduce "latest in 3.0.x" I guess. not much to code. >> >> >> I think that's the most logical behavior we need for testing HAProxy >> without breaking the CI because of a major change in the library. >> What we need is to test our code for each of our commit, if the CI break >> on our commit because we changed the lib version it's difficult to know >> where the issue is. >> >> Maybe we could have a separated CI job with the "latest" version, so we >> ensure >> that this is running correctly before integrating the version to the >> "per-commit" CI jobs. What do you think about that? It seems like a good >> compromise to me. >> > > it is easy to fix currently. > for example, LIBRESSL_VERSION=latest is broken after 3.6.0 release > I temporarily changed to LIBRESSL_VERSION=3.5.3 > > as for separate job (not integrated into build matrix), it makes sense to > use it with master branch. > but Willy does not like paying attention to master branch of OpenSSL, > because its api is not stable at all. > > >> >> >> -- >> William Lallemand >> >
