Open pkoelemij opened 5 years ago
stale[bot]
commented
5 years ago This issue has been automatically marked as stale because it has not had activity from the community in the last 30 days. It will be closed if no further activity occurs within 10 days. If the issue is labelled with any of the work labels (e.g bug, enhancement, documentation, or tests) then the issue will not auto-close.
PlagueHO
commented
5 years ago Thanks for raising this @lemoneydes . I think being able to override the cert store to use would definitely be useful. It appears that this might have been intended at some point but the dots weren't connected.
I'll assign this as an enhancement.
tmeckel
commented
5 years ago @PlagueHO it's not only an enhancement; the code at
won't work well when there are more certificates with the same subject and or with thumbprint. Especially when we release the restriction on Cert:\LocalMachine\MY as mentioned by the initial author, because you can place the same certificate (regarding it's Thumbprint) without any hassle into different certificate store locations.
In addition Set-TargetResource locates the specified certificate differently than Get-TargetResource especially Get-TargetResource doesn't honer the parameter CertificateSubject at all, whereas Get-TargetResource does.
So from my point of view 2 additional bugs here at least. Perhaps even more by a deeper investigation.
tmeckel
commented
5 years ago @PlagueHO Another catch :-D
Test-TargetResource doesn't check if the current certificate used for the current binding is the same as defined in the current DSC configuration.
PlagueHO
commented
5 years ago Good catches there @tmeckel ! Changed to bug.
tmeckel
commented
5 years ago Implies the label 'bug' any priority or is it just a label? I'm working on the MSFT_xDSCWebService.psm1module anyway (issues: #463, #460) I could try to fix this here as well.
@mhendric
mhendric
commented
5 years ago I would think Bug > Enhancement as far as priority goes. But I'm not aware of any way that we're currently tracking Issue priorities relative to each other. It would be good to throw these on a board of some sort and come up with priorities of what we want addressed first, and what is dependent on other issues being addressed. I'm open to suggestions on how to accomplish that. It also might be good to have more priority labels than just "High Priority" (i.e. have medium and low too).
tmeckel
commented
5 years ago @mhendric After reading your message I thought about what's my opinion about this and I came to the conclusion that because this is a community driven project and we thus can't rely on permanently assigned resources it might not be worth putting the effort in prioritizing all issues based on it's type.
In a community project a people pick up issues already on the list (or even provide PRs directly for issues they came accross while using the code) with which they feel comfortable and think they can provide a benefit for the project. If you try to align this with a priority list you might only drive away those people. I do agree that somebody should do a quick triage on incoming issues (is this a task for a maintainer? at least you and @PlagueHO) and because of this we might need more detailed labels. This also would be helpful in the community calls while "reporting" eg to @kwirkykat
Microsoft is such huge company and is overseeing so many projects here on GitHub, has no best practice crystallized here yet that could be adopted? How are the other DSC projects handle this?
Hi there! Is there a reason for hard coding Cert:\LocalMachine\MY for the DSC config?.
This caused some extra configuration because for example win-acme doesnt use the Cert:\LocalMachine\MY as default, but I could think of a couple more use cases. For our particular situation it would be preferable to have this configurable in the DSC config. The $Store parameter is already implemented in the method. Would this be something useful to implement? I wouldn't mind expanding the module and sending a pull request.