Saturday, 10 March 2018

WebUSB - An unexpected update...

In January at my new(ish) user group Momentum Meetups, I presented on "Reaching out beyond the Chrome" (although suffering from food poisoning so I was definitely going green at points!). It included WebUSB and WebBluetooth. I was excited by how powerful it was and even had a colleague present something we had been prototyping in out work place.

During the talk I mentioned security and how it had been designed so it only works on https and there's a permission model where you have to approve the device before it can be used.

Unfortunately this week it came to light that Authentication devices could be bypassed via USB. These devices are a great way of proving you are who you say you are on the web beyond basic 2FA text's or applications. So being able to be able to bypass them via WebUSB is a big deal :(

My Original Security Slide
A few days later Google then disabled WebUSB by default effectively killing it off until such a time where its made secure.

I'm now worried about the future of WebUSB as it's taken years to really gain adoption and it's never had cross-browser support. So my advice for now is to not consider using it and hopefully something else will come out or it will become more secure.

I really liked the prospect of WebUSB and the prototype my colleague and I made for our work was super powerful and opened up a new avenue for interactions but security has to be paramount over convenience. The particular attack vector feels limited to certain types of phishing attacks but security has to take priority.

[Update 12/03/2018] As expected the Chromium team have got a patch for this by baking in a blacklist that can be updated via the team. This has been pushed out via Chrome 65. It feels like a necessary change but the risk is still present for new devices.

Monday, 5 March 2018

a different day a different msbuild issue...

Recently I started working on a small tweak to an existing web project, its a small internal dashboard sort of thing nothing complicated about it.

However after I started working on it I found I could no longer build the project it came up with:
): error CS1525: Invalid expression term 'throw'
): error CS1002: ; expected
 error CS1043: { or ; expected
 error CS1513: } expected
: error CS1014: A get or set accessor expected
: error CS1513: } expected
 When I looked at the location of the build errors I could see some perfectly valid code, all be it C#7:

 public IEnumerable<AttemptResult> Attempts
get => _attempts;
set => _attempts = (value ?? Enumerable.Empty<AttemptResult>());

Why would it not like the C#7 code, i'm in VS2017 it should all be correct, when I double checked the language setting under Advanced Build Settings it correctly had C# latest major version, so it wasn't a case the project had got pinned to a language version.

I next turned to the build log to see what was happening and noticed something odd:
The core compile was using
c:\repositories\xxxx\packages\Microsoft.Net.Compilers.1.0.0\build\..\tools\csc.exe /noconfig /nowarn:1701,1702,2008 /nostdlib+ /errorreport:prompt /warn:4 /define:TRACE /errorendlocation /preferreduilang:en-US  etc...

This wasn't pointing at roslyn compiler unlike normal projects which always use:
 C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Roslyn\csc.exe /noconfig /nowarn:1701,1702,2008 /nostdlib+ /errorreport:prompt

So i inspected my nuget packages for the project and found it was using Microsoft.Net.Compiles and in its description i says:
 Referencing this package will cause the project to be built using the specific version of the C# and Visual Basic compilers contained in the package, as opposed to any system installed version.
The project referenced version 1 which was released in 2015, definitively before C#7 was a thing. I followed the link in the Nuget package to get to the Rosyln GitHub page which details the NuGet packages and what each version means.  

I was correct C#7 wasn't a thing until V2, so i can update the package and get it working. However I was puzzled as to why it was even referenced ... turns out I have no idea! Nothing was actually dependent on it, however we used to have Application Insights in the project so it might have been left over from then.

A problem solved and a lesson learnt for the future :)

Friday, 2 March 2018

project.json doesn't have a runtimes section, add '“runtimes”: { “win”: { } }' to project.json within a .Net Class Library

Recently I've started experiencing weird build errors when switch branches on a product.
Error : Your project.json doesn't have a runtimes section. You should add '"runtimes": { "win": { } }' to your project.json and then re-run NuGet restore.
It's a weird sounding error and the fact it mentions project.json makes it sound like a hangup from when .Net Core and Standard were using project.json files before they became .csproj files again.

My first thought to resolve this is always try a clean and build, particularity when swapping branches things could get left hanging around but this doesn't work.

I took a closer look at the projects affected and the cause is to do with one of the branches of our product. It's an early development branch of a new feature where the project has become .Net Standard 2.0 but also targets .Net 4.5, where as the support and main dev branch are still the full framework class libraries.  The cause is most certainly to do with how msbuild produces different artifacts upon each branch.

The solution: simply delete the obj folder from the affected projects when you switch branches, there are no left over artifacts then affecting the build.

For those that are interested or if you don't want to be deleting your obj folder all the time the error actually only happens if there is a project.assets.json within the obj folder as even the new .csproj generates this file. Delete it when you switch branches and your builds will work again.

[Update 16/03/2018]
This error can also seen as
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets(186,5): error : Your project is not referencing the ".NETPortable,Version=v4.5,Profile=Profile7" framework. Add a reference to ".NETPortable,Version=v4.5,Profile=Profile7" in the "frameworks" section of your project.json, and then re-run NuGet restore.

Again its the same issue, delete the project.assets.json and everything will build fine.