-
Notifications
You must be signed in to change notification settings - Fork 17.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: x/sys/windows: add various bcrypt.dll, crypt32.dll and ncrypt.dll functions #64819
Comments
For that issue, what ended up getting merged is a fix to use After that issue was fixed, I didn't add any of the new >15 param syscalls to |
@dagood , thanks for the explanation. But why put those One more thought: should I add 20 new functions in |
In microsoft/go-crypto-winnative it's useful to be able to add/change syscall implementations without involving upstream and new versions of x/sys. For another example, https://github.com/microsoft/go-winio also has a lot of syscall implementations. But these examples just show one way to get unblocked, and as far as I know, it's fine to contribute the new syscalls to I see that some recent new syscalls were tracked as bugs rather than proposals, so the new ones might be easy to accept:
I'd go ahead and provide the list of syscalls for now if you can--I'm not familiar with the bar for accepting new ones, and I think others can help split up the list if necessary. (CC @golang/windows) |
As far as I know, you don't need a proposal to add Windows APIs. It is fine to just send a CL with your changes. The only problem is for someone to review its correctness, because we won't be able change them once merged. But maybe we can all review them together. Alternatively you can just use https://github.com/microsoft/go-crypto-winnative/blob/main/internal/bcrypt/bcrypt_windows.go as suggested by @dagood . Or even have your own version. Or maybe contribute whatever you need to https://github.com/microsoft/go-crypto-winnative/blob/main/internal/bcrypt/bcrypt_windows.go if Microsoft are OK with your contribution. Thank you. Alex |
As this is going to be the first time contributing to the go code, I do prefer to do it the go way. But the learning curve seems to be a bit steep. I've read the contribution guide and the referenced documents, but I still don't dare to start. Is there a more detailed step-by-step guide somewhere about contributing to the
For starters I'll just start working and testing with a branch in a local copy. Once I've implemented and tested all the API calls I need, I'll get back here to try to find the correct (go) way to contribute my additions. One more note: it looks like |
I'm not aware of a more specific guide, personally I was able to get started with https://go.dev/doc/contribute. It includes a brief step-by-step at https://go.dev/doc/contribute#gerrit_overview, but then also has a much more in depth step-by-step starting at https://go.dev/doc/contribute#checkout_go. They have some steps that are specific to the Submitting via GitHub rather than Gerrit is also valid, and it might be easier to find a detailed guide for it because GitHub's more widely used. For the bulleted questions, I'll take a shot (as a fellow contributor, to be clear):
In general, for non-trivial contributions you can just file an issue first to figure this out. Providing the list of API calls in this issue might let someone proactively point out any that might deserve more specific attention, but I doubt that will be a problem here and going ahead with the CL would be fine.
The branch name doesn't actually affect the CL submission process on Gerrit. It's only for your use, to e.g. organize multiple CLs locally. On GitHub, the branch name shows up in the pull request UI, but it also isn't important.
I don't think so, in this case. Perhaps keep in mind that
I'm not aware of one. However, there is not only one way to translate a given parameter. For example, both I don't remember seeing a place where the rules/possibilities are laid out. I hope I just missed it, that would be nice to see! |
@dagood thanks for your extensive reply. I'll document what I'm doing, step-by-step, as well as the parameter translations. |
As part of this work, can we also introduce |
Change https://go.dev/cl/572255 mentions this issue: |
Proposal Details
For an application I needed a number of functions to sign data with a PKI certificate stored on a smartcard (so the private key is not accessible). I would like to contribute these functions to
x/sys/windows
so I do not have to implement them in my own code. I used the existingx/sys/windows
code as a reference, so my code should fit in nicely. The only question I still have is whether I'm allowed to use the newsyscall.SyscallN()
function: as far as I saw it's not yet being used inx/sys/windows
right now (but I did not search all files for it).The text was updated successfully, but these errors were encountered: