Backdoors, GitHub Package Manager, cleanup.

[scovetta]

This PR has a bunch of updates:

• Add new backdoor detection rules (based on recent attacks seen).
• Add preliminary support for Golang, fix GitHub processors (removed libgit2 dependency) (Type initializer error for libgit2sharp on Linux #172).
• Minor improvements (version sorting, test coverage, nullability)
• Remove self-contained csproj attribute (was preventing building in Visual Studio, debugging, etc.)

[gfs]

Looks good.

[gfs]

If you do want to do it this way. I would strongly recommend just converting the numbers into numbers before listing them to make this way simpler.

I reread this and it looks like you are comparing actual strings in here not just numbers.

[scovetta]

for (int i=0; i<minLength; i++)
{
    if (int.TryParse(x[i], out int xInt) &&
        int.TryParse(y[i], out int yInt))
    {
        if (xInt > yInt) return -1;
        if (yInt > xInt) return 1;
    }
    else
    {
        var compValue = x[i].CompareTo(y[i]);
        if (compValue != 0) return compValue;
    }
}

If the strings are integers (e.g. the 234 in v1.234.56 and the 78 in v1.78.0), then it should compare 234 to 78 as integers and show that 234 comes after it.

(Or maybe I missed something.)

[gfs]

I tested and it does not sort integers like that when you pass them as strings. That said the string comparison looks like its only when something is not a number so I think it is OK. My comment was just explaining why I crossed out my initial comment.

> list
List<string>(0) { }
> list.Add("234");
> list.Add("73");
> list.Sort()
> list
List<string>(2) { "234", "73" }

[scovetta]

@daalcant Could you take a look at the .csproj files (with me setting <SelfContained>false</SelfContained>) to see if we need to adjust the build scripts? This was needed to get the solution to build in Visual Studio.

[daalcant]

@daalcant Could you take a look at the .csproj files (with me setting <SelfContained>false</SelfContained>) to see if we need to adjust the build scripts? This was needed to get the solution to build in Visual Studio.

I'll need to update the build strategy. I think if we build each project individually then do a self-contained build of the solution it will achieve what we're looking for. After I test locally I'll update this PR.

[daalcant]

I added some changes to prepare for updating the pipeline build order. I expect builds to fail until I commit the next set of changes; just checking to make sure that tests run as expected.

[daalcant]

Running into more issues here. Looks like there was a recent breaking change to the way self-contained project references are validated in .NET 5. Going to fiddle with the configurations and the ValidateExecutableReferencesMatchSelfContained property.

https://docs.microsoft.com/en-us/dotnet/core/compatibility/sdk/5.0/referencing-executable-generates-error

[daalcant]

@scovetta Builds seem to be working again (for now). Unfortunately I'm pretty sure our setup is unsupported and could break in the future. The .NET docs suggest we shouldn't expect to bundle our executables in a single folder the way we have been, which is why we keep running into problems. I'm open to discuss later but I suppose this is fine for the short term.

I performed some basic testing of the framework dependent netcore app and the self-contained Windows and Linux apps. All of the executables run, and I was able to successfully demo oss-download against pkg:cargo/rand on each platform as a spot check. Feel free to merge if this is good enough.

[daalcant]

Reviewed build items, LGTM

[scovetta]

Thanks @daalcant! Merging now.