Re: Failures on "Generate Build Matrix"

[Tim Düsterhus]

William,

On 12/22/22 18:20, William Lallemand wrote:

You need to be logged to see the logs of the CI, I don't know if it is
only accessible to the people in the haproxy group or if it only need to
be logged to github.



Logs are visible to every logged-in user, no matter if they are part of 
the organization or not.


But as Ilya already confirmed, any "plaintext" secrets that appear in 
the logs are redacted. Of course this does not protect against base64 
encoded tokens appearing in the logs, e.g. when using HTTP "Basic" 
authentication.


Best regards
Tim Düsterhus

Re: Failures on "Generate Build Matrix"

[Tim Düsterhus]

Willy,

On 12/22/22 19:01, Willy Tarreau wrote:

On Thu, Dec 22, 2022 at 11:56:24PM +0600,  ??? wrote:

you can limit token scope to read repo information.


But the request you're making with it concerns a different project
(openssl), will this work ?



Just to confirm: Yes, this works. This is purely a matter of 
"unauthenticated" vs "authenticated" API access. The rate limits are 
different. Unauthenticated users get 60 requests per hour per IP 
address, the limit for authenticated users is much higher, because the 
account can be uniquely identified.


For the GITHUB_TOKEN we're using now, the limit is at 1000r/h: 
https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#requests-from-github-actions


Best regards
Tim Düsterhus

Re: Failures on "Generate Build Matrix"

[Tim Düsterhus]

Hi y'all,

On 12/23/22 15:24, William Lallemand wrote:

I passed some time doing tests and reading the github configuration, in
fact we don't need to generate a token ourselves and to add it to the
secret configuration.

Github has a GITHUB_TOKEN which is generated at the beginning of the job
and destroyed at the end, so I just add it in the environment as
recommended in the documentation.

https://docs.github.com/en/actions/security-guides/automatic-token-authentication#about-the-github_token-secret

So we can remove any token that was generated for this problem, it is
not useful.


Bad timing, I was on my Christmas vacation :-)

I've just read through this entire thread: The solution William found is 
the correct one and the one I would've suggested, had I seen this earlier.


Best regards
Tim Düsterhus

Re: Failures on "Generate Build Matrix"

[Willy Tarreau]

On Fri, Dec 23, 2022 at 03:24:47PM +0100, William Lallemand wrote:
> On Fri, Dec 23, 2022 at 12:14:15AM +0600,  ??? wrote:
> > haproxy/vtest.yml at master · chipitsine/haproxy (github.com)
> > 
> > 
> > secret name can be arbitrary, for example "TOKEN".
> > env variable is GITHUB_API_TOKEN
> > 
> 
> I passed some time doing tests and reading the github configuration, in
> fact we don't need to generate a token ourselves and to add it to the
> secret configuration.
> 
> Github has a GITHUB_TOKEN which is generated at the beginning of the job
> and destroyed at the end, so I just add it in the environment as
> recommended in the documentation.
> 
> https://docs.github.com/en/actions/security-guides/automatic-token-authentication#about-the-github_token-secret
> 
> So we can remove any token that was generated for this problem, it is
> not useful.

Good catch! That also explains why they don't want us to create one
whose name starts with GITHUB_ :-)

Thanks,
Willy

Re: Failures on "Generate Build Matrix"

[William Lallemand]

On Fri, Dec 23, 2022 at 12:14:15AM +0600, Илья Шипицин wrote:
> haproxy/vtest.yml at master · chipitsine/haproxy (github.com)
> 
> 
> secret name can be arbitrary, for example "TOKEN".
> env variable is GITHUB_API_TOKEN
> 

I passed some time doing tests and reading the github configuration, in
fact we don't need to generate a token ourselves and to add it to the
secret configuration.

Github has a GITHUB_TOKEN which is generated at the beginning of the job
and destroyed at the end, so I just add it in the environment as
recommended in the documentation.

https://docs.github.com/en/actions/security-guides/automatic-token-authentication#about-the-github_token-secret

So we can remove any token that was generated for this problem, it is
not useful.

Regards,
-- 
William Lallemand

Re: Failures on "Generate Build Matrix"

[Илья Шипицин]

haproxy/vtest.yml at master · chipitsine/haproxy (github.com)


secret name can be arbitrary, for example "TOKEN".
env variable is GITHUB_API_TOKEN

пт, 23 дек. 2022 г. в 00:12, Willy Tarreau :

> On Fri, Dec 23, 2022 at 12:08:29AM +0600,  ??? wrote:
> > not perfect, but it works
>
> Can you please elaborate ? You sent a two-line screenshot of
> something I have no idea what this is nor what to do with it.
> Are you suggesting to rename the token or something else ? I'm
> sorry but your messages are too cryptic for me Ilya.
>
> Willy
>

Re: Failures on "Generate Build Matrix"

[Willy Tarreau]

On Fri, Dec 23, 2022 at 12:08:29AM +0600,  ??? wrote:
> not perfect, but it works

Can you please elaborate ? You sent a two-line screenshot of
something I have no idea what this is nor what to do with it.
Are you suggesting to rename the token or something else ? I'm
sorry but your messages are too cryptic for me Ilya.

Willy

Re: Failures on "Generate Build Matrix"

[Илья Шипицин]

not perfect, but it works

[image: image.png]


from github point of view, if token is bad, you'll get 401.
as long as I'm getting 200, I assume it works for "openssl" org as well :)

пт, 23 дек. 2022 г. в 00:04, Willy Tarreau :

> On Thu, Dec 22, 2022 at 11:56:24PM +0600,  ??? wrote:
> > you can limit token scope to read repo information.
>
> I tried anyway, it created one and failed with:
>
> Failed to add secret. Secret names must not start with GITHUB_.
>
> So I guess we should have tried it before committing the entry :-/
>
> Willy
>

Re: Failures on "Generate Build Matrix"

[Willy Tarreau]

On Thu, Dec 22, 2022 at 11:56:24PM +0600,  ??? wrote:
> you can limit token scope to read repo information.

I tried anyway, it created one and failed with:

Failed to add secret. Secret names must not start with GITHUB_.

So I guess we should have tried it before committing the entry :-/

Willy

Re: Failures on "Generate Build Matrix"

[Willy Tarreau]

On Thu, Dec 22, 2022 at 11:56:24PM +0600,  ??? wrote:
> you can limit token scope to read repo information.

But the request you're making with it concerns a different project
(openssl), will this work ?

Willy

Re: Failures on "Generate Build Matrix"

[Илья Шипицин]

you can limit token scope to read repo information.

[image: image.png]

чт, 22 дек. 2022 г. в 23:49, Willy Tarreau :

> On Thu, Dec 22, 2022 at 11:35:35PM +0600,  ??? wrote:
> > here's how it works
> >
> > (unfortunately, github does not allow secret named GITHUB_ , so I created
> > secret "TOKEN" and assigned it to variable GITHUB_API_TOKEN)
> >
> > I also added "env" to print all variables, you can value of
> > GITHUB_API_TOKEN is masked. is it set to wrong value, so api call failed:
> >
> >
> https://github.com/chipitsine/haproxy/actions/runs/3759885064/jobs/6389967966
>
> OK, it was supposed to appear at line 27 and was maked in the console
> output. And the backtrace didn't reveal the value of the argument, just
> their name. So normally if it fails in urllib.request.Request() it should
> only log the URL and "headers", nothing more.
>
> In that case I think it's acceptable. We'll just need to watch from time
> to time and destroy the token if we notice it for whatever other reason
> (e.g. debug mode enabled in HTTP fetch showing headers etc). Sorry for
> being annoying but you'll agree that the whole security around this is
> extremely fragile and solely relies on the console filtering known
> strings!
>
> So now the next step will be for me to find my way through the painful
> settings interface. I'll find Tim's previous howto in my mails.
>
> Thanks!
> Willy
>

Re: Failures on "Generate Build Matrix"

[Willy Tarreau]

On Thu, Dec 22, 2022 at 11:35:35PM +0600,  ??? wrote:
> here's how it works
> 
> (unfortunately, github does not allow secret named GITHUB_ , so I created
> secret "TOKEN" and assigned it to variable GITHUB_API_TOKEN)
> 
> I also added "env" to print all variables, you can value of
> GITHUB_API_TOKEN is masked. is it set to wrong value, so api call failed:
> 
> https://github.com/chipitsine/haproxy/actions/runs/3759885064/jobs/6389967966

OK, it was supposed to appear at line 27 and was maked in the console
output. And the backtrace didn't reveal the value of the argument, just
their name. So normally if it fails in urllib.request.Request() it should
only log the URL and "headers", nothing more.

In that case I think it's acceptable. We'll just need to watch from time
to time and destroy the token if we notice it for whatever other reason
(e.g. debug mode enabled in HTTP fetch showing headers etc). Sorry for
being annoying but you'll agree that the whole security around this is
extremely fragile and solely relies on the console filtering known
strings!

So now the next step will be for me to find my way through the painful
settings interface. I'll find Tim's previous howto in my mails.

Thanks!
Willy

Re: Failures on "Generate Build Matrix"

[Илья Шипицин]

here's how it works

(unfortunately, github does not allow secret named GITHUB_ , so I created
secret "TOKEN" and assigned it to variable GITHUB_API_TOKEN)

I also added "env" to print all variables, you can value of
GITHUB_API_TOKEN is masked. is it set to wrong value, so api call failed:

https://github.com/chipitsine/haproxy/actions/runs/3759885064/jobs/6389967966

чт, 22 дек. 2022 г. в 23:28, Willy Tarreau :

> On Thu, Dec 22, 2022 at 06:20:26PM +0100, William Lallemand wrote:
> > On Thu, Dec 22, 2022 at 06:12:46PM +0100, Willy Tarreau wrote:
> > > On Thu, Dec 22, 2022 at 11:00:26PM +0600,  ??? wrote:
> > > > I'm not sure if it possible to issue organization based token (not a
> > > > personal one).
> > > >
> > > > As for visibility, secrets are not visible for pull requests.
> > >
> > > My concern is not that they are in PR or any such thing, but they're
> > > passed in HTTP requests and function arguments in python scripts. So
> > > once we get a failure, if the failed request is dumped into the CI's
> > > logs, or if the python interpreter emits a stack trace with all
> > > arguments to the functions in the stack, the build logs will reveal
> > > the secret. Maybe there's a way to be certain that the logs from the
> > > python script are never dumped to publicly accessible logs, or to
> > > redirect them to files only accessible to authorized people, and that
> > > would be fine, but until this, I don't know what such guarantees we
> > > have. This is my concern regarding the use of this token like this.
> > >
> > > Thanks,
> > > Willy
> >
> > You need to be logged to see the logs of the CI, I don't know if it is
> > only accessible to the people in the haproxy group or if it only need to
> > be logged to github.
>
> OK. At least this is something we need to verify before proceeding. I
> don't know if anyone has access to an account not part of the users
> here. Or conversely maybe we can try to look for another project's
> CI logs.
>
> Willy
>

Re: Failures on "Generate Build Matrix"

[Willy Tarreau]

On Thu, Dec 22, 2022 at 06:20:26PM +0100, William Lallemand wrote:
> On Thu, Dec 22, 2022 at 06:12:46PM +0100, Willy Tarreau wrote:
> > On Thu, Dec 22, 2022 at 11:00:26PM +0600,  ??? wrote:
> > > I'm not sure if it possible to issue organization based token (not a
> > > personal one).
> > > 
> > > As for visibility, secrets are not visible for pull requests.
> > 
> > My concern is not that they are in PR or any such thing, but they're
> > passed in HTTP requests and function arguments in python scripts. So
> > once we get a failure, if the failed request is dumped into the CI's
> > logs, or if the python interpreter emits a stack trace with all
> > arguments to the functions in the stack, the build logs will reveal
> > the secret. Maybe there's a way to be certain that the logs from the
> > python script are never dumped to publicly accessible logs, or to
> > redirect them to files only accessible to authorized people, and that
> > would be fine, but until this, I don't know what such guarantees we
> > have. This is my concern regarding the use of this token like this.
> > 
> > Thanks,
> > Willy
> 
> You need to be logged to see the logs of the CI, I don't know if it is
> only accessible to the people in the haproxy group or if it only need to
> be logged to github.

OK. At least this is something we need to verify before proceeding. I
don't know if anyone has access to an account not part of the users
here. Or conversely maybe we can try to look for another project's
CI logs.

Willy

Re: Failures on "Generate Build Matrix"

[William Lallemand]

On Thu, Dec 22, 2022 at 06:12:46PM +0100, Willy Tarreau wrote:
> On Thu, Dec 22, 2022 at 11:00:26PM +0600,  ??? wrote:
> > I'm not sure if it possible to issue organization based token (not a
> > personal one).
> > 
> > As for visibility, secrets are not visible for pull requests.
> 
> My concern is not that they are in PR or any such thing, but they're
> passed in HTTP requests and function arguments in python scripts. So
> once we get a failure, if the failed request is dumped into the CI's
> logs, or if the python interpreter emits a stack trace with all
> arguments to the functions in the stack, the build logs will reveal
> the secret. Maybe there's a way to be certain that the logs from the
> python script are never dumped to publicly accessible logs, or to
> redirect them to files only accessible to authorized people, and that
> would be fine, but until this, I don't know what such guarantees we
> have. This is my concern regarding the use of this token like this.
> 
> Thanks,
> Willy

You need to be logged to see the logs of the CI, I don't know if it is
only accessible to the people in the haproxy group or if it only need to
be logged to github.

-- 
William Lallemand

Re: Failures on "Generate Build Matrix"

[Willy Tarreau]

On Thu, Dec 22, 2022 at 11:00:26PM +0600,  ??? wrote:
> I'm not sure if it possible to issue organization based token (not a
> personal one).
> 
> As for visibility, secrets are not visible for pull requests.

My concern is not that they are in PR or any such thing, but they're
passed in HTTP requests and function arguments in python scripts. So
once we get a failure, if the failed request is dumped into the CI's
logs, or if the python interpreter emits a stack trace with all
arguments to the functions in the stack, the build logs will reveal
the secret. Maybe there's a way to be certain that the logs from the
python script are never dumped to publicly accessible logs, or to
redirect them to files only accessible to authorized people, and that
would be fine, but until this, I don't know what such guarantees we
have. This is my concern regarding the use of this token like this.

Thanks,
Willy

Re: Failures on "Generate Build Matrix"

[Илья Шипицин]

I'm not sure if it possible to issue organization based token (not a
personal one).

As for visibility, secrets are not visible for pull requests.

чт, 22 дек. 2022 г. в 22:57, Илья Шипицин :

> there are couple of steps left (no hurry, because "matrix.py" is backward
> compatible)
>
> 1. issue "some kind of token".
>either Personal Access Tokens (Classic) (github.com)
>    (no time limit)
>or  Fine-grained Personal Access Tokens (github.com)
>   (1year token)
>
> 2. add issued token to secrets:
> https://github.com/haproxy/haproxy/settings/secrets/actions/new
>
> 3. add secret definition to workflow, like this: haproxy/coverity.yml at
> master · haproxy/haproxy (github.com)
> 
>
> чт, 22 дек. 2022 г. в 22:43, Willy Tarreau :
>
>> On Thu, Dec 22, 2022 at 10:32:22PM +0600,  ??? wrote:
>> > I attached a patch. It keeps current behaviour and is safe to apply.
>> >
>> > in order to make a difference, github token must be issued and set via
>> > github ci settings.
>>
>> OK I understand better now, thanks! I didn't know that there was a
>> difference between auth vs non-auth.
>>
>> I'm having a few questions though:
>>   - where are we supposed to find that token to fill the variable (most
>> likely Tim will facepalm and come rescue me here :-))
>>
>>   - how can we certain that there isn't a risk that this token leaks
>> into build logs which are public ? Because that's what I absolutely
>> hate with the principle of github insecure tokens, it's that they're
>> purely private keys that have to be blindly copy-pasted everywhere.
>>
>> It would be wise to be certain we don't become the de-facto standard
>> github API token provider for all anonymous users...
>>
>> Thanks,
>> Willy
>>
>

Re: Failures on "Generate Build Matrix"

[Илья Шипицин]

there are couple of steps left (no hurry, because "matrix.py" is backward
compatible)

1. issue "some kind of token".
   either Personal Access Tokens (Classic) (github.com)
   (no time limit)
   or  Fine-grained Personal Access Tokens (github.com)
  (1year token)

2. add issued token to secrets:
https://github.com/haproxy/haproxy/settings/secrets/actions/new

3. add secret definition to workflow, like this: haproxy/coverity.yml at
master · haproxy/haproxy (github.com)


чт, 22 дек. 2022 г. в 22:43, Willy Tarreau :

> On Thu, Dec 22, 2022 at 10:32:22PM +0600,  ??? wrote:
> > I attached a patch. It keeps current behaviour and is safe to apply.
> >
> > in order to make a difference, github token must be issued and set via
> > github ci settings.
>
> OK I understand better now, thanks! I didn't know that there was a
> difference between auth vs non-auth.
>
> I'm having a few questions though:
>   - where are we supposed to find that token to fill the variable (most
> likely Tim will facepalm and come rescue me here :-))
>
>   - how can we certain that there isn't a risk that this token leaks
> into build logs which are public ? Because that's what I absolutely
> hate with the principle of github insecure tokens, it's that they're
> purely private keys that have to be blindly copy-pasted everywhere.
>
> It would be wise to be certain we don't become the de-facto standard
> github API token provider for all anonymous users...
>
> Thanks,
> Willy
>

Re: Failures on "Generate Build Matrix"

[William Lallemand]

On Thu, Dec 22, 2022 at 05:37:59PM +0100, William Lallemand wrote:
> On Thu, Dec 22, 2022 at 10:32:22PM +0600, Илья Шипицин wrote:
> > I attached a patch. It keeps current behaviour and is safe to apply.
> > 
> > in order to make a difference, github token must be issued and set via
> > github ci settings.
> > 
> > Ilya
> > 
> 
> I just pushed it, thank you.
> 

I'm kind of confused, where is the token supposed to be created? I'm
only seeing the "personal access tokens".

Thanks.

-- 
William Lallemand

Re: Failures on "Generate Build Matrix"

[Willy Tarreau]

On Thu, Dec 22, 2022 at 10:32:22PM +0600,  ??? wrote:
> I attached a patch. It keeps current behaviour and is safe to apply.
> 
> in order to make a difference, github token must be issued and set via
> github ci settings.

OK I understand better now, thanks! I didn't know that there was a
difference between auth vs non-auth.

I'm having a few questions though:
  - where are we supposed to find that token to fill the variable (most
likely Tim will facepalm and come rescue me here :-))

  - how can we certain that there isn't a risk that this token leaks
into build logs which are public ? Because that's what I absolutely
hate with the principle of github insecure tokens, it's that they're
purely private keys that have to be blindly copy-pasted everywhere.

It would be wise to be certain we don't become the de-facto standard
github API token provider for all anonymous users...

Thanks,
Willy

Re: Failures on "Generate Build Matrix"

[William Lallemand]

On Thu, Dec 22, 2022 at 10:32:22PM +0600, Илья Шипицин wrote:
> I attached a patch. It keeps current behaviour and is safe to apply.
> 
> in order to make a difference, github token must be issued and set via
> github ci settings.
> 
> Ilya
> 

I just pushed it, thank you.

-- 
William Lallemand

Re: Failures on "Generate Build Matrix"

[Илья Шипицин]

I attached a patch. It keeps current behaviour and is safe to apply.

in order to make a difference, github token must be issued and set via
github ci settings.

Ilya

чт, 22 дек. 2022 г. в 16:57, Willy Tarreau :

> On Thu, Dec 22, 2022 at 04:47:09PM +0600,  ??? wrote:
> > what if I make it conditional, i.e. if github token is defined via env,
> > make non anonymous api call,
>
> I'm sorry, Ilya, but I have no idea what this means :-)
>
> Willy
>
From c4e038b014c3c8e565857bc971d200b091192d93 Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin 
Date: Thu, 22 Dec 2022 22:27:37 +0600
Subject: [PATCH] CI: enable github api authentication for OpenSSL tags read

github api throttles requests with no auth, thus we can enable
GITHUB_API_TOKEN env variable. if not set, current behaviour is kept
---
 .github/matrix.py | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/.github/matrix.py b/.github/matrix.py
index ffc3414b9..72e6b1a85 100755
--- a/.github/matrix.py
+++ b/.github/matrix.py
@@ -26,7 +26,9 @@ def clean_ssl(ssl):
 return ssl.replace("_VERSION", "").lower()
 
 def determine_latest_openssl(ssl):
-openssl_tags = urllib.request.urlopen("https://api.github.com/repos/openssl/openssl/tags;)
+headers = {'Authorization': 'token ' + environ.get('GITHUB_API_TOKEN')} if environ.get('GITHUB_API_TOKEN') else {}
+request = urllib.request.Request('https://api.github.com/repos/openssl/openssl/tags', headers=headers)
+openssl_tags = urllib.request.urlopen(request)
 tags = json.loads(openssl_tags.read().decode('utf-8'))
 latest_tag = ''
 for tag in tags:
-- 
2.38.1

Re: Failures on "Generate Build Matrix"

[Willy Tarreau]

On Thu, Dec 22, 2022 at 04:47:09PM +0600,  ??? wrote:
> what if I make it conditional, i.e. if github token is defined via env,
> make non anonymous api call,

I'm sorry, Ilya, but I have no idea what this means :-)

Willy

Re: Failures on "Generate Build Matrix"

[Илья Шипицин]

what if I make it conditional, i.e. if github token is defined via env,
make non anonymous api call,

чт, 22 дек. 2022 г. в 16:27, Willy Tarreau :

> On Thu, Dec 22, 2022 at 03:49:34PM +0600,  ??? wrote:
> > it is something I was afraid of "HTTP Error 403: rate limit exceeded".
> > ok, I'll try to deal with that
>
> Yep I've also seen a 429 this morning, indicating we were making too many
> requests to clone a repo. I think this is purely a problem of threshold on
> github's side. They might need to white-list their own CI servers or to
> raise some thresholds to reasonable levels.
>
> Willy
>

Re: Failures on "Generate Build Matrix"

[Willy Tarreau]

On Thu, Dec 22, 2022 at 03:49:34PM +0600,  ??? wrote:
> it is something I was afraid of "HTTP Error 403: rate limit exceeded".
> ok, I'll try to deal with that

Yep I've also seen a 429 this morning, indicating we were making too many
requests to clone a repo. I think this is purely a problem of threshold on
github's side. They might need to white-list their own CI servers or to
raise some thresholds to reasonable levels.

Willy

Re: Failures on "Generate Build Matrix"

[Илья Шипицин]

it is something I was afraid of "HTTP Error 403: rate limit exceeded".
ok, I'll try to deal with that

чт, 22 дек. 2022 г. в 15:41, William Lallemand :

> Hi Guys,
>
> Since a few days I'm seeing some failure on the "Generate Build Matrix"
> part of
> the CI, the request.urlopen() seems to fail the urlopen(), it's easy to
> restart
> it manually but it happened to me a few times recently.
>
> Do you think that would be possible to cache these values so the script
> don't
> fail ? or maybe just let the "latest" fail.
>
> Generating matrix for type 'master'.
> Traceback (most recent call last):
>   File "/home/runner/work/haproxy/haproxy/.github/matrix.py", line 167, in
> 
> ssl = determine_latest_openssl(ssl)
>   File "/home/runner/work/haproxy/haproxy/.github/matrix.py", line 29, in
> determine_latest_openssl
> openssl_tags = urllib.request.urlopen("
> https://api.github.com/repos/openssl/openssl/tags;)
>   File "/usr/lib/python3.10/urllib/request.py", line 216, in urlopen
> return opener.open(url, data, timeout)
>   File "/usr/lib/python3.10/urllib/request.py", line 525, in open
> response = meth(req, response)
>   File "/usr/lib/python3.10/urllib/request.py", line 634, in http_response
> response = self.parent.error(
>   File "/usr/lib/python3.10/urllib/request.py", line 563, in error
> return self._call_chain(*args)
>   File "/usr/lib/python3.10/urllib/request.py", line 496, in _call_chain
> result = func(*args)
>   File "/usr/lib/python3.10/urllib/request.py", line 643, in
> http_error_default
> raise HTTPError(req.full_url, code, msg, hdrs, fp)
> urllib.error.HTTPError: HTTP Error 403: rate limit exceeded
>
> Thanks!
> --
> William Lallemand
>

Failures on "Generate Build Matrix"

[William Lallemand]

Hi Guys,

Since a few days I'm seeing some failure on the "Generate Build Matrix" part of
the CI, the request.urlopen() seems to fail the urlopen(), it's easy to restart
it manually but it happened to me a few times recently.

Do you think that would be possible to cache these values so the script don't
fail ? or maybe just let the "latest" fail.

Generating matrix for type 'master'.
Traceback (most recent call last):
  File "/home/runner/work/haproxy/haproxy/.github/matrix.py", line 167, in 

ssl = determine_latest_openssl(ssl)
  File "/home/runner/work/haproxy/haproxy/.github/matrix.py", line 29, in 
determine_latest_openssl
openssl_tags = 
urllib.request.urlopen("https://api.github.com/repos/openssl/openssl/tags;)
  File "/usr/lib/python3.10/urllib/request.py", line 216, in urlopen
return opener.open(url, data, timeout)
  File "/usr/lib/python3.10/urllib/request.py", line 525, in open
response = meth(req, response)
  File "/usr/lib/python3.10/urllib/request.py", line 634, in http_response
response = self.parent.error(
  File "/usr/lib/python3.10/urllib/request.py", line 563, in error
return self._call_chain(*args)
  File "/usr/lib/python3.10/urllib/request.py", line 496, in _call_chain
result = func(*args)
  File "/usr/lib/python3.10/urllib/request.py", line 643, in http_error_default
raise HTTPError(req.full_url, code, msg, hdrs, fp)
urllib.error.HTTPError: HTTP Error 403: rate limit exceeded

Thanks!
-- 
William Lallemand