RequestError: self-signed certificate #489
Comments
|
having same issue. Probably comes from here: ffa17a8 the only solution that I found was to downgrade the plugin version( npm install @semantic-release/[email protected]) |
|
some more details here: sindresorhus/got#2149 |
Downgrading did the trick! Thanks! But the whole way of using workarounds for dealing with self-signed certificates remains highly unsatisfying in general... An official mechanism, option etc. to enable self-signed certificates would be highly appreciated. I even tried adding the server certificate to the trusted list: That works on my maschine 👍 , but still fails if run in a docker container 👎. |
|
In container same issue. Adding certs by or using @semantic-release/[email protected] works fine !!! Thanks @geigervlad |
i have a really hard time getting behind adding an option to disable verification of tls certificates. part of the decision to use a self-signed certificate is taking on the extra complexity of configuring systems to trust that certificate. i recognize that there used to be a way around this by directly telling node to skip verification, and i wouldnt expect us to take steps to prevent that. however, i think us defining an explicit option would encourage more folks to do this and suggests that we support avoiding security measures.
there is a reason that this warning is provided. i dont think we should be encouraging folks to ignore this. |
|
@geigervlad @jagiella @artem-shestakov The previous behavior was restored in https://github.com/semantic-release/gitlab/releases/tag/v10.1.4. I’ll leave this issue open until it’s clear how we solve this long-term. |
Full ack, but I also don’t want to break existing workflows if we can somehow avoid it. I agree that adding this as configuration option might send the wrong signal. Let’s see if there’s any response from the |
|
would it be valid to handle this through documentation? does gitlab provide any official documentation for using self-signed certs and adding them to the trust chain that we could link to? or maybe recommend use of free certs from a vendor that is based on a trusted root CA? i'm trying to be careful how i say this, but i dont consider a workflow that only works by following unsecure practices to be a valid approach and especially not one that is officially supported by semantic-release. i imagine we dont call that out in documentation currently, but i'm open to that being added if we feel we need to call it out. i see this more as encouragement to take steps to fill a security hole in the release process for the software supply chain of the projects that were following this approach. another concern i have after reverting the upgrade to the latest version of got is that we are now a major version behind again. that means that consumers of this plugin would not get security fixes that are only applied to the latest channel. that puts all consumers of this plugin at risk rather than only those choosing to follow unsecure handling of their self-signed certs. we now have a couple of options for versions of this plugin that continue to work for those flows. folks that dont want to update their cert handling right away can choose to stay on one of those version, but i'd feel better keeping up with the latest channel of got. if folks want to encourage the got team to revert their decision, i feel like that is the place to request a way around this situation. i dont see this being a responsibility of semantic-release. |
|
OK, we need to updrade
I agree with your argumentation @travi that we should not encourage folks to apply bad security practices. I'd suggest we perform the update, but indicate a breaking change. Any objections/concerns? |
|
@travi @fgreinacher We use a gitlab instance exclusively in our intranet or via SSH tunnels / VPN access from home office. So our server is not and shall not ever be accessible from the public internet. We have chosen secure connection (https) using self-signed certificates over insecure connection (http) nevertheless and for now had no issues with it exept needing workarounds for the "self-signed" complaints of all kind of clients (browser, git), integrations and add-on (like semantic-release). What would be the correct way of getting rid of "bad security practices" in your opinion? |
|
@jagiella Fully understood. I'd say the clean way to solve it is via internal root CAs that manage such certificates. Does something like that exist in your place? Otherwise there should be a way to mark a specific self-signed certificate as trusted by the OS. I'd expected Node to accept such certificates. |
|
@fgreinacher to my knowledge we don't have an internal root CA yet. Marking the servers self-signed certificate as trusted by the OS works in general, but unfortunately fails if done inside a docker container (See my 2nd comment #489 (comment)). |
|
@jagiella a self-signed certificate still needs to be verified to be considered secure. otherwise, you could be missing evidence of a compromised supply chain (your pipeline server). there are various ways to configure your system to enable verification of the signature that are beyond the scope of support for the semantic-release teams. the simplest is to use a cert from a trusted root CA. you've clarified that is not an option for you. because of that, you've chosen a more painful path and it is up to you and your team to work through the details of proper verification. as mentioned above, if the security risks are not a concern to you, which your description of your desire to avoid certificate verification suggests, you can choose to use older versions of this plugin. |
i would say that it isn't necessary because this isn't really a change to this plugin directly and isn't actually an officially supported use case. that said, i think there is value in drawing attention to the fact that it is known that this will impact some consumers and this is an opportunity to encourage them to fix the gap in their supply chain security. there is also value in having a major bump to allow consumers to continue using an old version that continues to use the old got version without risk of an in-range version causing that to change. in short, i'm supportive of the change being treated as breaking. i think it would be valuable to link to this thread from the release notes (even if it is a modification after the release) for additional context. i would also recommend calling out that it is an option for folks to use an older version if they choose to ignore the security implications of using a self-signed cert without taking the steps to handle it in a trust verifying way. |
Bumps [cacheable-request](https://github.com/jaredwray/cacheable-request) to 10.2.7 and updates ancestor dependency [got](https://github.com/sindresorhus/got). These dependencies need to be updated together. BREAKING CHANGE: This version drops support for accepting untrusted TLS certificates via `NODE_TLS_REJECT_UNAUTHORIZED`. See #489 for details. Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
|
I just merged the upgrade, producing https://github.com/semantic-release/gitlab/releases/tag/v11.0.0. As mentioned above we are a critical part of many software supply chains and prioritize security over other qualities. I hope this is relatable for everyone, even if it causes some issues downstream. I'll leave this issue open a bit in case folks want to mention alternative solution approaches. |
Closing this now as there was no additional feedback :) |
|
Hey, thanks for this discussion. I'm commenting in case someone else finds this w/ the same problem I had.
I had the node environment variable set, but now obviously not working. I should have not needed it... it turns out that when you send a cert through nginx it must be the full chain cert If it does not come in this order then It was as simple as adding the cert chain into the end my gitlab cert file (
You can verify it after restarting nginx with |
|
@fgreinacher I agree with all the security arguments, you can find the discussion everywhere you look for ssl issues... however, there are a lot of guys runing gitlab in a box in their garage totally isolated from the outside world and just want stuff to work without the endless cert details. It would be cool if the code here could be tweaked to read that env var and pass it as the new parameter to |
|
Another way without completely disabling security. OS: Debian 11 (node:19 docker image) If you have own CA and certificates signed with it.Add CA to system trusted certs inside If you have selfsigned certificates.Add selfsigned cert: And then
This is really strange, why got not use system list of trusted certs. If any body know, please tell me =) |
|
And for now I completely understand. And I found solution!
|
|
Hi Everyone, thanks for all the great info above. From what I understand, this issue has been resolved and the current consesus is to either downgrade to semantic-release/gitlab v10.1.4 so that setting I thought I would just leave this here for what it is worth, in case this is an Alpine specific issue and it can save someone with a similar setup to mine some time. |
I've been trying the same thing without much success. |
|
Hi @Teles1 To have semantic-release/gitlab work with |
|
Hi @Teles1
To have semantic-release/gitlab work with `NODE_TLS_REJECT_UNAUTHORIZED=0` you need to explicitly install ***@***.******@***.***` installing the latest version will not work because the underlying libraries have made changes and no longer utilize `NODE_TLS_REJECT_UNAUTHORIZED=0`
I'm pretty sure I went as far back as 10.0.0 and it didn't work. The error
output was obviously different but when I dug down it pointed at my tls
certificate not being valid. I'll try again soon and let you know. Thank
you for taking the time to look into this for me.
edit: Yep. It did indeed work. I had problems with my token itself that didn't have API permissions. Thank you!
|
Adding the release:
stage: release
image: node:lts
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
variables:
NODE_OPTIONS: "--use-openssl-ca"
script:
- cp $CUSTOM_ROOT_CA /usr/local/share/ca-certificates/custom_ca.crt
- update-ca-certificates
- npm install semantic-release @semantic-release/gitlab @semantic-release/changelog @semantic-release/git
- npx semantic-release |
Since last weekend I get an error due to self-signed certificate. The setup that did the same job until now was:
ERROR:
Expected behavior (until last week):
The text was updated successfully, but these errors were encountered: