tsd
tsd copied to clipboard
DefinitelyTyped
SSL Cert Info
Hi, I am looking to be able to set a certificate location. For git I am using: http.sslcainfo="cert location" Is there a similar option for TSD?
Thx. M
We've got the same issue. strictSSL:false isn't an option because it disables SSL checking completely and the security folks won't have that. So I think what we really need is the ability to specify a CA file (like NPM does: https://docs.npmjs.com/misc/config#cafile).
@ericvw You mentioned in #218 that you're working towards fixing this issue. Where are you with that? I cloned this project and started poking around a bit then thankfully saw this existing issue. Are you aware of any blockers that need to be taken care of first?
@mikehaas763, I'm still (slowly) working on it. It hasn't been a super high priority for me at the moment. However, there is probably a bit more refactoring work that is needed so that the HTTP options and settings are configured once so that each instance of GithubLoader doesn't need configure the same set of options being passed down by each derived class.
Parsing a CA bundle will also need to be added since the underlying HTTP NodeJS library needs an array of certificates. I'm happy to discuss further offline about the details if you are interested in pushing this along.
Understood. I have some questions about your reply (clarity mainly). I think I'll be able to provide some time to help get this pushed along. You can reach me with my email on my profile.
I'm affected by this as well, and might be able to help. Did you hash out any implementation plan via email?
@ryepup no we didn't. My organization redirected me to work on something completely different for the time being that doesn't use TS so it just got put on hold I guess. If I begin work on the other thing in the future I am willing to spend the time doing this but there are no guarantees that will happen. The other thing is that TS now auto resolves to type definitions included with npm packages so personally I don't see much of a value in TSD any more. I'm sure there will always be other use cases that will require something like TSD though.
I did reach out to @mikehaas763 via the email on his GitHub profile page, but never received a reply :).
I partially agree with @mikehaas763's assessment. However, some npm packages are not TypesScript, so unless the maintainers are willing to include definitions for non-TypeScript npm packages, tsd will still be needed.
I am also backgrounding this because it's a bit more work than originally perceived in my original assessment.
Ok, I'm running into this while trying to use Visual Studio Code, which I think is delegating to tsd, but I'm not 100% sure of that.
https://github.com/request/request#tlsssl-protocol has an example of reading a PEM file, so following that might be a pretty straightforward implementation.
That part is the straight-forward part, the difficult part is properly piping that down to where it needs to get plugged in.
The other thing is that TS now auto resolves to type definitions included with npm packages so personally I don't see much of a value in TSD any more
@mikehaas763 There'll likely always be value in a project like TSD. I don't think it'll ever happen that every single type definition for every library on every package manager will become typed. However, going forward people should be contributing type definitions to the library and mitigate the issue.
I'm currently working on http://github.com/typings/cli which spawned out of refactoring this project (as mentioned in #150). We're currently interfacing with the TypeScript team to solve how this can be completely transparent (the tool would only exist for module authors, in other words). It's an interesting challenge.
As for the SSL problem, because now I'm deviating from the issue, I'm welcome to finding and merging a solution sooner rather than later into TSD. I'll continue to check in here, but if anyone wants to contribute a PR I'll review it ASAP.
There'll likely always be value in a project like TSD.
Although I don't necessarily agree with that:
...so personally I don't see much of a value in TSD any more.
which is why I also followed it up with
I'm sure there will always be other use cases that will require something like TSD though.
@mikehaas763 Sure, I understand what the word personally means. I didn't say anything in there to try and attack your statement. I was clarifying your statement around "...type definitions included with npm packages..." which sounds like everything is already working in TypeScript land, when we're still a longways off. I haven't even seen a way to create a pure TypeScript project yet that has no external type definitions (excluding ones that just don't have dependencies) as not every package will ever have included type definitions. Unless you're operating in a very walled garden of packages right now.
The problem with contributing type definitions back to projects, at the current point in time, is that unless you're starting at the root of the dependency tree and waiting for everything to merge as you go up and you land all the type definitions in the npm packages with zero kinks during that process, then it's just not feasible (yet) to rely on the node resolution strategy. But, I can't tell what you're building, so I made a very general post.