Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
RE: noproxy breakage
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Randall via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 27 Oct 2022 17:42:57 -0400
On October 27, 2022 5:30 PM, Daniel wrote:
>A regression in the noproxy filter functionality in 7.86.0 has been
suggested to be
>reason enough for a patch release:
>
> https://github.com/curl/curl/issues/9813
>
>We don't yet have any stated policy for how to judge when a bug is reason
>enough for a patch release but maybe this is the time to try to forumlate a
>guideline?
As a starting point, a common set of guidelines for justifying patch
releases include the following non-conflicting requirements:
1. Is there a high rated security advisory for which a fix is available?
2. Is there a data corruption during processing for which a fix is
available?
3. Is there a stack corruption that causes the software to prematurely
terminate for which a fix is available?
4. Does the fix not change any API, which would exclude a patch-level
release.
5. Is the fix of general applicability instead of one environment, OS
release, or platform?
6. Is there a malware attack vector that can be closed with an available
patch?
Just my off-the-cuff dump of what I have used on other projects for patch
release justification.
-Randall
Date: Thu, 27 Oct 2022 17:42:57 -0400
On October 27, 2022 5:30 PM, Daniel wrote:
>A regression in the noproxy filter functionality in 7.86.0 has been
suggested to be
>reason enough for a patch release:
>
> https://github.com/curl/curl/issues/9813
>
>We don't yet have any stated policy for how to judge when a bug is reason
>enough for a patch release but maybe this is the time to try to forumlate a
>guideline?
As a starting point, a common set of guidelines for justifying patch
releases include the following non-conflicting requirements:
1. Is there a high rated security advisory for which a fix is available?
2. Is there a data corruption during processing for which a fix is
available?
3. Is there a stack corruption that causes the software to prematurely
terminate for which a fix is available?
4. Does the fix not change any API, which would exclude a patch-level
release.
5. Is the fix of general applicability instead of one environment, OS
release, or platform?
6. Is there a malware attack vector that can be closed with an available
patch?
Just my off-the-cuff dump of what I have used on other projects for patch
release justification.
-Randall
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-10-27