2.4.9 Ep

0 views

Skip to first unread message

Candi Ruman

unread,

Aug 3, 2024, 5:11:16 PM8/3/24

to wellpremcentso

This release is a re-package of 2.4.8 because the previous Ruby 2.4.8release tarball does not install.(See [Bug #16197] in detail.)There are no essential change except their version numbers between 2.4.8 and 2.4.9.

Ruby 2.4 is now under the state of the security maintenance phase, untilthe end of March of 2020. After that date, maintenance of Ruby 2.4will be ended. We recommend you start planning the migration to newerversions of Ruby, such as 2.6 or 2.5.

You might have noticed that 2.4.8 was just released. That release broke one of our protocol analyzers for some Linux users. 2.4.9 replaces that release. The changes listed below include all changes in 2.4.8 and 2.4.9.

I'm checking out OpenCV as a possible solution to my needs for an optical ranging/orientation system, and have run into installation issues with OpenCV 2.4.9 on Visual Studio 2010 Professional. I don't generally have issues with setting up new development environments - I have toolchains for Atmel and Mircochip microcontrollers, SDKs for various platforms, etc. etc. etc. - but this is giving me fits.

My development environment is Visual Studio 2010 Pro SP1 on Windows 7 Ultimate x64 SP1. I get either LNK1104 (cannot open file) or LNK1107 (invalid/corrupt file) errors trying to compile a simple test program with OpenCV. My research on the 1104 error suggests a file path problem, and 1107 suggests the compiler is trying to load a DLL as a library.

Compile fails with error LNK1104: cannot open file 'opencv_core249d.dll'. If I change the Additional Dependencies entry for that file to include a full path to the file, compile fails with error LNK1107: invalid or corrupt file: cannot read at 0x310, affecting opencv_core249d.dll.

I've gone all over the Internet trying to figure out why I'm having this issue, since as near as I can tell I have VS2010 pointed in the right direction in every place it's required, and I've rebooted a good dozen times thus far in case it's a "rebooting Windows fixes it" type of problem (read: environment vars not updating), but to no avail.

EDIT: Also tried moving the OpenCV directory root over to a drive root so it's not inside a path that contains spaces, as I've found a few complaints of inconsistent handling of spaces in file paths on some installs of VS2010. This also made no difference - still getting 1104s no matter what I do.

What annoys me about this is that, as near as I can tell from the plethora of people discussing setting up OpenCV with VS2010, I have every relevant setting correct and it -still- won't work. I'm missing something that's important enough to stop the whole process but it's subtle enough that it's not catching my attention.

Got it working, but it was a convoluted process. I had to do a full compile from sources, and when that finished I had to instruct VS2010 to use \build\include in Include Directories, \build\lib\Debug in Library Directories. THEN it was able to "see."

LinkedIn and 3rd parties use essential and non-essential cookies to provide, secure, analyze and improve our Services, and to show you relevant ads (including professional and job ads) on and off LinkedIn. Learn more in our Cookie Policy.

WCAG 2.4.4 Link Purpose: In Context - level A and 2.4.9 Link Purpose: Link only - level AAA both relate to making links meaningful to users. The difference is that with 2.4.4, the users should be able to work out where the link will take them from the context surrounding the link, while according to 2.4.9, they should be able to do that from the link text alone.

Links are usually visually different from standard text. Screen readers try to mimic that functionality and allow users to pull up a list of links and navigate through that list quickly. However, if the list has 3 "Click here" and 4 " Find out more" links, users have to investigate the surrounding content to find out what these specifically refer to. If they can work out the meaning from the context surrounding the link, the learning content complies with the level A standard. However, in general, it's considered best practice to comply with the level AAA guideline and make the purpose or the destination of the link clear from the link alone.

Use hyperlink instead of the actual URL link wherever possible. That is because screen readers read out the full chain of the URL and that can be time-consuming. Not to mention that a chain of random numbers and letters are meaningless.
Try to keep the hyperlink short and more or less same or similar to the title of the destination page.
Because links opening in a new tab or window can be disorienting for some learners using assistive technology and it also breaks back-button history navigation, it's recommended that links are set to open in the same window. If users want to open links in a new window, they can do that by using their mouse or keyboard functions.
According to WCAG 1.4.11 Non-text Contrast (AA), the colour contrast between links and surrounding elements should be 3:1. (In most cases, the surrounding element refers to the surrounding text, but in addition, it may also refer to the background colour.)
Finally, "click" is uninclusive of users who do not use a mouse. Instead, using "select" or "follow" are better options.

This page lists all security vulnerabilities fixed in released versions of Apache HTTP Server 2.4. Each vulnerability is given a security impact rating by the Apache security team - please note that this rating may well vary from platform to platform. We also list the versions the flaw is known to affect, and where a flaw has not been verified list the version with a question mark.

Please note that if a vulnerability is shown below as being fixed in a "-dev" release then this means that a fix has been applied to the development source tree and will be part of an upcoming full release.

The initial GA release, Apache httpd 2.4.1, includes fixes for all vulnerabilities which have been resolved in Apache httpd 2.2.22 and all older releases. Consult the Apache httpd 2.2 vulnerabilities list for more information.

A partial fix for CVE-2024-39884 in the core of Apache HTTP Server 2.4.61 ignores some use of the legacy content-type based configuration of handlers. "AddType" and similar configuration, under some circumstances where files are requested indirectly, result in source code disclosure of local content. For example, PHP scripts may be served instead of interpreted.

A regression in the core of Apache HTTP Server 2.4.60 ignores some use of the legacy content-type based configuration of handlers. "AddType" and similar configuration, under some circumstances where files are requested indirectly, result in source code disclosure of local content. For example, PHP scripts may be served instead of interpreted.

Users are recommended to upgrade to version 2.4.60 which fixes this issue. Note: Existing configurations that access UNC paths will have to configure new directive "UNCList" to allow access during request processing.

Encoding problem in mod_proxy in Apache HTTP Server 2.4.59 and earlier allows request URLs with incorrect encoding to be sent to backend services, potentially bypassing authentication via crafted requests. This affects configurations where mechanisms other than ProxyPass/ProxyPassMatch or RewriteRule with the 'P' flag are used to configure a request to be proxied, such as SetHandler or inadvertent proxying via CVE-2024-39573. Note that these alternate mechanisms may be used within .htaccess.

Substitution encoding issue in mod_rewrite in Apache HTTP Server 2.4.59 and earlier allows attacker to execute scripts in directories permitted by the configuration but not directly reachable by any URL or source disclosure of scripts meant to only to be executed as CGI.

Improper escaping of output in mod_rewrite in Apache HTTP Server 2.4.59 and earlier allows an attacker to map URLs to filesystem locations that are permitted to be served by the server but are not intentionally/directly reachable by any URL, resulting in code execution or source code disclosure.

Substitutions in server context that use a backreferences or variables as the first segment of the substitution are affected. Some unsafe RewiteRules will be broken by this change and the rewrite flag "UnsafePrefixStat" can be used to opt back in once ensuring the substitution is appropriately constrained.

Vulnerability in core of Apache HTTP Server 2.4.59 and earlier are vulnerably to information disclosure, SSRF or local script execution via backend applications whose response headers are malicious or exploitable.

HTTP/2 incoming headers exceeding the limit are temporarily buffered in nghttp2 in order to generate an informative HTTP 413 response. If a client does not stop sending headers, this leads to memory exhaustion.

An attacker, opening a HTTP/2 connection with an initial window size of 0, was able to block handling of that connection indefinitely in Apache HTTP Server. This could be used to exhaust worker resources in the server, similar to the well known "slow loris" attack pattern.

When a HTTP/2 stream was reset (RST frame) by a client, there was a time window were the request's memory resources were not reclaimed immediately. Instead, de-allocation was deferred to connection close. A client could send new requests and resets, keeping the connection busy and open and causing the memory footprint to keep on growing. On connection close, all resources were reclaimed, but the process might run out of memory before that.

This was found by the reporter during testing of CVE-2023-44487 (HTTP/2 Rapid Reset Exploit) with their own test client. During "normal" HTTP/2 use, the probability to hit this bug is very low. The kept memory would not become noticeable before the connection closes or times out.

Configurations are affected when mod_proxy is enabled along with some form of RewriteRule or ProxyPassMatch in which a non-specific pattern matches some portion of the user-supplied request-target (URL) data and is then re-inserted into the proxied request-target using variable substitution.