https://linen.dev logo
Join Slack
Powered by
I put 301 redirect to s3 bucket for quick mitigati...
# fluent-bit
c
I put 301 redirect to s3 bucket for quick mitigation , can I ask your help to understand if it mitigated your issues for now?
👍 2
m
Thanks- but for your sake, shouldn't that be 302?
c
good idea, made it 302
j
It works on my side now
m
Same, thanks!
c
working for me now. i had been getting 
dnf makecache
errors on all my boxes all morning. thank you!
s
Also confirmed working in my pipelines.
c
great, thanks all. sorry about inconvenience caused 🎉
🙌 1
🦸 1
p
Well done @Celalettin, you deserve a raise
☝️ 3
😄 2
j
Thanks @Celalettin!!
g
Thanks @Celalettin!
s
Hi @Celalettin This redirect is causing another issue where curl won't allow the key download I have fixed it in #11137 PR please have a look
r
This redirect to the s3 bucket will break all installations accessing the repo via a proxy. In our infrastructure the redirect to 
<https://s3.amazonaws.com/packages.fluentbit.io/>
is not defined in the proxy and breaks as expected with this error:
Copy code
Curl error (56): Failure when receiving data from the peer for <https://s3.amazonaws.com/packages.fluentbit.io/almalinux/9/repodata/repomd.xml> [Received HTTP code 403 from proxy after CONNECT]
c
I am taking a look today and considering options to remove redirect it was temporary solution for Friday evening before weekend
👍 1
r
thank you very much @Celalettin for looking at this
why are we changing the way clients get the GPG key for the fluent-bit repository? ref: https://github.com/fluent/fluent-bit/pull/11137 This is not a good idea. This can be a security issue. Not using -L with curl guarantees that the gpg key has to be found in the address defined in the client repository. Accepting a redirect when getting the repository gpg key does not guarantee that the client is talking with the correct/official repo. Another important issue with redirects in repository addresses is that they break all systems using a proxy to allow the access to the repository from internal infrastructures. From a security perspective, allowing access to 
<https://s3.amazonaws.com/>
in a package proxy is madness. The whole point with package/repo proxies is to have control over which external resources outside the infrastructure a server has access to in order to install software.
s
@Rafael Martinez Guerrero The change was suggested since after the s3 redirect, anyone using the install.sh would be unable to access the keys thus preventing installation If the redirect is removed, the change can be reverted however I'm not sure how anyone except the maintainers of the infra would be able to force a redirect from the primary URL Please share your thoughts on the same
p
I figured out why the packages server went down at least now so bringing it back up
👍 4
r
@Saksham If the server serving the repository is compromised and redirects are allowed, I could redirect all traffic to "my repository", with my code and my packages, signed by my gpg-key without changing anything in the official repo. Not allowing the redirect when getting the gpg key, will protect the repository more, even if the server is compromised. Because I will have to get control of the infrastructure signing the official packages and change the content of the official repo to be able to get control over the code served to clients.
s
@Rafael Martinez Guerrero understood, fair point. Thanks for taking out the time for the explanation Reverting to the old command seems to be the best approach once the redirect is fixed
👍 1
c
ok there should be no redirect now
👍 1
r
Now everything seems to be working fine for us using a proxy to access the repository. Thank you very much for your help.
Open in Slack
PreviousNext
Powered by