Dependency issue with new version of the ImageSharp

[dejanmauer]

Dependency issue with new version of the ImageSharp

[svenso]

There is now a security issue on latest working version of image sharp (2.1.6):
GHSA-65x7-c272-7g7r

Edit:
In the mean time, there is a fixed 2.1.7 version available from ImageSharp: https://github.com/SixLabors/ImageSharp/releases/tag/v2.1.7

[johnwc]

@ststeiger Can you please comment on all these requests on updating for ImageSharp. This is becoming an issue.

[TonyValenti]

Hi @ststeiger -
I just created this PR:
https://github.com/ststeiger/PdfSharpCore/compare/master...TonyValenti:PdfSharpCore:master?expand=1

Which upgrades various packages, including ImageSharp, to their latest stable, secure versions.

[Thomas-HG]

Is there any news on this subject ? We are using this great library but this issue starts to be a big pain on our side :(

Thanks !

[TonyValenti]

@dejanmauer - lots of folks are running into this issue. I am really hopeful that @ststeiger will enable us to use the latest version of ImageSharp easily.

I've created this branch:
https://github.com/TonyValenti/PdfSharpCore

That enables the latest version of ImageSharp for modern .NET versions and uses the older version for legacy .NET versions.

Here's to hoping @ststeiger incorporates it!

[TonyValenti]

Later today I'll be submitting a PR that contains everything necessary to resolve this security issue.

[johnwc]

Will it include being able to use v3 of ImageSharp. And the bigger question, will @ststeiger respond and approve the PR.

[TonyValenti]

Yes. V3 for modern .NET and V2 for framework.

We'll have to wait and see if the maintainer of this package accepts it.

[TonyValenti]

@johnwc - my PR is here if you want to take a look.

[johnwc]

What are the main differences between the two versions of ImageSharpImageSource? The two look almost exactly the same, minus a few method call differences. If that is the case, wouldn't it be better to just make the compile time directives within the few minor differences, rather than duplicate the code for each? I think it would be easier to maintain that way.

[TonyValenti]

@johnwc -
Here is a screen shot showing the compare:

In my experience, when you're dealing with subtle variances like this, you can easily get yourself in trouble by having a single file where you #if things in and out. It is much safer and easier to maintain to branch the file.

[johnwc]

It would be better to maintain one file with a few compile time directives, than two files with almost same code. Think of someone else coming in and only changing one file for a security flaw. If it was in the same file, it would be seen and updated at the same time. Also, visual studio makes it very clear on what directive is currently being worked on and debugged with its coloring of the enabled directive. In my 25 years of development, I have never come across an issue of compile time directives being in a file in relation to this version vs that version compiling. The directives make it very clear what is going on.

[TonyValenti]

That's not a big deal to me either way as long as we can get the maintainer to merge and publish an update.

[vebaspect]

Bump. :)

[mtarlac]

same problem here ;(

[tossnet]

#421

[balkarov]

+1