Update 17.2 from 17.0 #8087
Update 17.2 from 17.0 #8087
Conversation
On Linux, the default /tmp folder is shared across all users and accessible by them. There are some cases in which we put sensitive information in temp and assume it's fine because on Windows, it is. This doesn't actually fix that assumption, since we're currently waiting for a new API that will be introduced in .NET 7 that will make a folder with appropriate permissions. However, this PR changes all the issues Eric Erhardt identified such that they go through a single code path, so to fix the security issue afterwards just requires changing the one place in our code. It did occur to me that we may not be able to use that API, in which case I can just write something to make a folder with a random name under temp then tweak its permissions.
…e-17.2-from-17.0
Forgind
added
the
merge-when-branch-open
|
Note: merge, not squash |
|
/azp run |
|
Azure Pipelines failed to run 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines failed to run 1 pipeline(s). |
|
/azp run |
1 similar comment
|
/azp run |
|
Azure Pipelines failed to run 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines failed to run 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines failed to run 1 pipeline(s). |
|
@Forgind can you update the build definition away from |
|
The only reference to NetCore1ESPool-Public seems to be in source-build.yml; can you explain how that's connected to azp not running? I also see a lot of NetCore1ESPool-Internal, so do you just mean switching Public to Internal there? |
Sure! One of the first things Azure DevOps does when trying to start a job is parse its definition, including expanding all of the "templates" that go into it. Lines 231 to 235 in 038f9ba So it gets pulled into that. The next thing AzDO does is try to find all the pools referenced by the different jobs, so it can start finding machines to execute on. That step fails, producing errors like the one here https://dev.azure.com/dnceng-public/public/_build/results?buildId=72153&view=results
That error can happen for two reasons, that it kinda hints at: either the pool really doesn't exist, or the pipeline doesn't have authorization to use it. In this case, it's the former, because the pool names changed because of some policy stuff that we were told about via email.
I do not! We should follow the migration guidance, but in this case the file is in |
|
That was a great explanation, thanks! I'll probably refer back to this at some point. And it looks like you were spot on with the arcade update. I triggered an arcade update (and set darc up to check for arcade updates for 17.2 on a regular basis), and it did indeed change the pool (among other changes) and not to NetCore1ESPool-Internal. I imagine we can merge the arcade update, then pull it into this PR, and we'll be good. |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
4 participants
Brings changes to the 17.0 branch into 17.2.