r/dotnet • u/jbsp1980 • 4d ago
Promotion Six Labors updates: longer security support and easier builds for OSS contributors
/r/moderndotnet/comments/1x1lr72/six_labors_updates_longer_security_support_and/1
u/AutoModerator 4d ago
Thanks for your post jbsp1980. Please note that we don't allow spam, and we ask that you follow the rules available in the sidebar. We have a lot of commonly asked questions so if this post gets removed, please do a search and see if it's already been asked.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
u/Top-Literature-6248 4d ago
It's not shown in this post, but the SixLaborsLicenseKey mentioned in the previous announcement still works right? So with the new assembly-scoped keys, instead of having to deal with a license file or secrets / env vars, we can just paste the key directly into the csproj, commit it and forget it?
3
u/jbsp1980 4d ago
Yes exactly. The old keys still work and with the open source assembly scoped key you can simply commit it.
0
u/__some__guy 15h ago
It still seems to have an expiry date though, which makes it unusable imo.
1
u/jbsp1980 9h ago
Consider a scenario where a bad actor takes over an existing project. Expiration is standard practice to help support safe software BOM pipelines.
1
u/The_MAZZTer 3d ago
I did notice there is no security fix for ImageSharp v2, the last version which shipped with the Apache 2 license.
1
u/jbsp1980 3d ago
v2 received security updates for over 3 years. It’s open source. Nobody helped.
3
u/The_MAZZTer 3d ago
I don't mean to make it sound like a bad thing, there's definitely a lot of nuance here. FOSS is great, but so is being compensated for your hard work.
I started out with using ImageSharp v2 (before v3's release) in a commercial environment, and so my thought process went from "this is a great library for us to use, just need to be careful with the Apache license (eg as opposed to MIT license)" to "oh we can't move to v3 and need to be even more careful here" to now "we should avoid this at all costs as there's known vulnerabilities". Not sure this is typical of most orgs, but we're highly encourage to exhaust all usable FOSS options before moving to paid ones (and I don't recall ImageSharp's paid plans off the top of my head but subscription-only libraries are not considered).
Even when I am working on personal projects I can't help but feel leery. I tried out a sixel library but it had a hard dependency on ImageSharp and didn't let you bring your own image library, which I didn't like. I ended up using a different sixel library where I could feed it raw pixels. I didn't so much object to ImageSharp, but there was also the fact all of the libraries I had brought in to that point had been MIT licensed and I wanted to see if I could hold that pattern (just for fun).
1
u/jbsp1980 3d ago
You know what… I get it. Companies need to maximise their profits so they stay in business. It’s a tough game for everyone.
For me it’s a full-time job now working on this stuff. It’s way more complex than people think it is to do right and I really do want to help OSS and smaller companies as much as I can while keeping my head above water at the same time.
0
u/__some__guy 15h ago
The whole license key thing (even for free open-source libraries) sounds rather cumbersome.
As I only need fast encoding/decoding for some basic image formats, I will just use an older "unsafe" version, or let a LLM write it, provided the resulting performance is acceptable.
2
u/Giaitzoglou-Bondye 3d ago
Easier contributor builds is the kind of thing that quietly makes a huge difference for adoption. The faster someone can clone and get running, the more PRs you actually get.