Author Topic: Adding .svg to allowed attachment file types? (Read 5739 times)

Nominal Animal · « **on:** February 23, 2022, 04:48:23 am »

Would it be possible to add .svg to the allowed upload attachment file suffix list?
I do not think it is necessary to add any extensions to the SimpleMachines Forum software, just add the file suffix to the allowed suffixes' list.

Current browsers support SVG files just like PNG, GIF, and JPEG images. SimpleMachines Forum also supports SVG images; it just does not allow uploading .svg files as an attachment.

Consider Larry Ewing's classix Tux logo, a 94015 byte SVG file:

which is displayed above using [img]https://www.nominal-animal.net/answers/tux-by-larry-ewing.svg[/img] .

(If one removes the width and height attributes of the target SVG file SVG element, only leaving the viewBox attribute, the SVG image will naturally scale to the maximum size possible in the allowed space, see e.g. https://www.nominal-animal.net/answers/tux-by-larry-ewing-unsized.svg.)

Inkscape is an easy to learn application for creating, editing, and manipulating SVG files, and is freely available for basically all operating systems, but all vector graphics packages nowadays do support SVG.

Diagrams, including circuit diagrams, are better described in vector graphics formats like SVG: file size should be smaller, and visual fidelity much better. Many free web tools like EasyEDA do allow easy export in SVG form, too.

I myself put the images on my own web site, and just link to them (as shown above), but I think it would make sense to allow SVG file uploads as normal image attachments, too. It would help with both image fidelity and file size (using less server resources).

emece67 · « **Reply #1 on:** February 23, 2022, 06:27:46 am »

Berni · « **Reply #2 on:** February 23, 2022, 06:36:03 am »

I agree the SVG format is one of the best vector graphics formats out there. It is well supported by software, does not break so easily from one software to the next, no huge amounts of legacy baggage, no big corporation pushing the format.

The only other widely usable way to send vector graphics is PDF but i had that go wrong in so many ways.

magic · « **Reply #3 on:** February 23, 2022, 09:17:46 am »

Quote from: Nominal Animal on February 23, 2022, 04:48:23 am

Consider Larry Ewing's classix Tux logo, a 94015 byte SVG file:

Quote from: Nominal Animal on February 23, 2022, 04:48:23 am

Diagrams, including circuit diagrams, are better described in vector graphics formats like SVG: file size should be smaller

April Fools is next month

I don't necessarily disagree with the proposal, but you picked a wrong example, perhaps.

Ian.M · « **Reply #4 on:** February 23, 2022, 09:28:57 am »

Unfortunately allowing SVG files without a robust server side SVG validator and malware scanner would permit cross-site scripting attacks to be hosted at EEVblog, so its not as simple as just adding .svg to the permitted extension list.

See: https://www.fortinet.com/blog/threat-research/scalable-vector-graphics-attack-surface-anatomy

magic · « **Reply #5 on:** February 23, 2022, 09:43:59 am »

Quote

Scalable Vector Graphics (SVG) is an XML-based vector image format for two-dimensional graphics with support for interactivity and animation. The SVG specification is an open standard developed by the World Wide Web Consortium (W3C) since 1999.

Nevermind, you have changed my mind. It's pure evil

Correct me if I'm wrong, but it's not just that malicious SVG could be hosted on the forum, but merely permitting SVG files to be embedded by [img] tags enables attacks hosted at nominal-animal.net to be executed on this forum's visitors. Is the whole thing really that braindamaged?

edit
Embedding SVG by <img> tags which is what the forum [img] tags do is supposed to disable the most dangerous features of the format. So mere embedding from other sites may be OK if you trust browser implementations to handle this mess right.

Berni · « **Reply #6 on:** February 23, 2022, 10:32:33 am »

Wait you can just stick javascript into SVG and it simply executes!? Why would a vector graphics format need scripting and intractable elements? What idiot thought that was a good idea

Okay yeah, SVG is a terrible idea in that case.

So... once again we are back at PDF garbage as the most universal vector graphics format.

magic · « **Reply #7 on:** February 23, 2022, 10:41:02 am »

Depending on what software renders it, and depending on how the image is embedded when it comes to HTML, yes, that's exactly what can happen.

PDF also supports embedding MalwareScript code.

Berni · « **Reply #8 on:** February 23, 2022, 10:44:40 am »

Ah great...

So what is left there as vector formats? DXF? I think the 1980s just called that they want there format back... at least back then they didn't have 20 different versions of the format while most software only reads 1/8th of said versions.

Ian.M · « **Reply #9 on:** February 23, 2022, 10:49:53 am »

Quote from: magic on February 23, 2022, 09:43:59 am

edit
Embedding SVG by <img> tags which is what the forum [img] tags do is supposed to disable the most dangerous features of the format. So mere embedding from other sites may be OK if you trust browser implementations to handle this mess right.

How locked down is *YOUR* browser? Mine is more locked down than average but eevblog.com is on the whitelist, so I *really* wouldn't like malicious SVGs to be hostable here in case the black hats come up with a new SVG exploit for it. Exploits on sites not on my whitelist don't bother me so much as the chances of anything getting executed are, for me, much smaller. Of course if you've 'drunk the advertising and social networking kool-aid' you are probably running a 'vanilla' install of a popular browser so are wide open to any zero-day exploits.

Also, permitting .svg attachments will attract *MORE* spammers and self-desribed '1337 hAcK3rZ'.

Nominal Animal · « **Reply #10 on:** February 23, 2022, 01:14:00 pm »

Quote from: Ian.M on February 23, 2022, 09:28:57 am

Unfortunately allowing SVG files without a robust server side SVG validator and malware scanner would permit cross-site scripting attacks to be hosted at EEVblog, so its not as simple as just adding .svg to the permitted extension list.

Crap, forgot about that. I think this came up before, either here or in some other forum.

One robust method would be to reject all SVG uploads that contain "<!ENTITY", or script or foreignObject elements (including in explicit named XML namespaces). For SimpleMachines 2.0.x, this is a simple addition to Sources/Sub-Post.php:createAttachment() just before security checks for images, and therefore a rather simple modification to SMF.

That does nothing to the Billion laughs attack (a recursive self-reference), though. Many applications use the <use xlink:href="#id" ... /> element pattern, so the only reliable way to filter those out is to test-render the SVG image, for example to create a thumbnail image. If it has any shenanigans like that, the upload will fail. (If an external program is used with strict process memory and runtime limits, it'd be bounded and fast, too.)

Note, however, that anyone can do the Billion laughs attack right now anyway, by using [img]url-to-nasty-svg[/img], so I'm not sure if trying to protect against it makes any sense. Also, the equivalent attack for Zip files (zip of death) is not defended against either.

Hmm, perhaps I should post the needed changes as a patch, upstream, because they already have (some) SVG support enabled? That way it'd help all SMF 2.0.x users, not just a single site.

thm_w · « **Reply #11 on:** February 23, 2022, 10:04:52 pm »

Quote from: magic on February 23, 2022, 09:17:46 am

I don't necessarily disagree with the proposal, but you picked a wrong example, perhaps.

Transparency was lost though, although that is rarely useful here.

magic · « **Reply #12 on:** February 23, 2022, 10:50:16 pm »

Because it's a screenshot from the forum

GIF and PNG both support transparency if they want to.

OTOH, I just noticed that the beak came out posterized after GIF encoding

Well, I could have uploaded PNG which is 24 bit lossless and still half the size of the original XML blob

magic · « **Reply #13 on:** February 23, 2022, 11:07:01 pm »

BTW, I have no idea about real world efficiency of SVG. I mean, it's uncompressed XML

so it cannot be great, but it's not a dumb bitmap format OTOH.

That being said, GIF isn't too bad either. Here's a real world schematic with almost 100 components in 32KB GIF.
https://www.eevblog.com/forum/projects/opamps-die-pictures/?action=dlattach;attach=1190312;image

Produced from the ASC vector format

The schematic is 16KB plus definitions of all the symbols (~500 bytes per symbol so maybe ~3KB total).

I guess SVG fanboys can upload something of comparable complexity to support their case

Nominal Animal · « **Reply #14 on:** February 24, 2022, 05:21:15 am »

The reason I included Tux, is to show that it works on all browsers, even for complex images. It is not just vector graphics, but uses SVG filters and other advanced functions.

By replacing the width and height attributes with viewBox attribute in the SVG element in the file, you get a perfectly scaling version. See e.g. https://www.nominal-animal.net/answers/tux-by-larry-ewing-unsized.svg (92k), especially if you have a 4k display.

Compare to magic's GIF image, which on my display is quite mushy around the letters and quite blocky at the diagonal lines. It works, but isn't nice.

Quote from: magic on February 23, 2022, 11:07:01 pm

I guess SVG fanboys can upload something of comparable complexity to support their case

Berni · « **Reply #15 on:** February 24, 2022, 06:18:35 am »

Seams like vector formats in general are security nightmares.

The next commonly supported vector file is WMF/EMF. It is also widely supported by vector drawing software and was not limited to Windows as it was originally designed for it. It would render in browsers just fine for a while but all popular browsers have dropped support for it due to..... yes once again remote code execution exploits.

PDF has vulnerability issues too but it is so widespread that it is impossible to kill the format now.

This is getting ridiculous, is there ANY vector format out there that is not full of security holes? (Apart from annoying ones that need special software to open where people likely don't even look for holes because they are too obscure)

Ed.Kloonk · « **Reply #16 on:** February 24, 2022, 06:32:10 am »

Quote from: Berni on February 24, 2022, 06:18:35 am

Seams like vector formats in general are security nightmares.

The next commonly supported vector file is WMF/EMF. It is also widely supported by vector drawing software and was not limited to Windows as it was originally designed for it. It would render in browsers just fine for a while but all popular browsers have dropped support for it due to..... yes once again remote code execution exploits.

PDF has vulnerability issues too but it is so widespread that it is impossible to kill the format now.

This is getting ridiculous, is there ANY vector format out there that is not full of security holes? (Apart from annoying ones that need special software to open where people likely don't even look for holes because they are too obscure)

The thing to watch is the remote code execution enablization. I'm surprised the cathedral doesn't keep more of an eye on this. It's always after the horse has bolted. Then they say Hey! you shouldn't have done that!

Berni · « **Reply #17 on:** February 24, 2022, 07:58:03 am »

Well it is one thing when they find a specific crash inside the software that renders the file. Like setting the length of some data block as negative that then causes the parser to crash in just the right way to lead to image data being executed as code. The vector formats are much more complex than bitmap formats since they have to represent much more than just an array of pixel values. This is more of the reason why WMF is vulnerable since it is simply a fancy list of windows graphics API calls that can be passed silly parameters with no checks at all. The format was meant for exchange between applications on the same machine anyway, so for that intended use it was not vulnerable since the application tricking it into the malicious API call could just make the call itself without the help of WMF. But this morphed into an actual portable file format where this is a problem. But you could create a more robust parser for that.

The SVG thing is worse. They are working on creating a format that is specifically designed to be easily shared between people over the internet and even be supported by web browsers. Then during that someone goes "You know it would be great if this format designed for storing pictures could also contain any valid javascript code and make requests into the internet" and nobody brings up any concern about that. Why does a image format need such capabilities in the first place.

Just do one thing and do it well. Just take a look at PNG, it ticks all the boxes without any unnecessary crap. The format can represent any pixel format under the sun be it Grayscale, RGB, CYMK or any weird collor mapping, can do pelleted colors like GIF, can do proper transparency better than GIFs binary transparancy, can do animations just like GIF, does better compression than GIF, includes space for metadata (unlike the hack JPEG needs to just tack it on after the file ends), like JPEG it can be progressively loaded and still shows an image if corrupt. Perhaps the only thing missing is lossy compression support for photos, but we already have JPEG doing a great job at that, so does not try to solve a solved problem.

Nominal Animal · « **Reply #18 on:** February 24, 2022, 08:25:55 am »

Additional testing, for those interested:

The red and blue areas below contain a trivial cross-site scripting test. If your browser allows cross-site scripting across domains, the red and blue areas, when clicked, will pop up a prompt (JavaScript Alert) saying "red" or "blue".

Mine (Firefox 97.0 on x86-64 Linux) does nothing, unless the above image is hosted on the same domain as the page it is shown in.
HTML and foreign object inclusion only occurs within the SVG image area. It does not "leak" outside the image rectangle.

The tiny little link in the green area is a HTML link, that if clicked, pops up a JavaScript alert saying "link", if scripts are allowed within the HTML fragment inside the SVG image. Mine does not.
XML entity references are only effective within the SVG image itself. They do not affect the interpretation of the HTML code where the SVG image is displayed.

Aside from making SVG images so complex or recursive that they can be used for denial-of-service, I believe that using SVG images from a different domain is actually safe on current browsers. At least, on my browser, the abovementioned security issues (aside of too-complex/too-recursive SVG files) do not occur, if the SVG image displayed is hosted on a different domain.

This means that it is may not be a good idea to allow SVG attachments at this time, except if the upload is to a different domain, say an image or file hosting service.

If you do load the example page containing the two above images, you can test how the behaviour of the images differ when they are hosted in the same server/domain as the HTML page itself. However, on my browser, the abovementioned security issues do not occur: even on the same server, the SVG images behave as if they were in a different domain! Only when you open the SVG images themselves directly in your browser (first, second), can I get the JavaScript to function.

Simply put, the browser I use is secure against cross-site scripting via SVG files, even if those SVG files include HTML objects. If everyone used similarly protected browsers, there would be no danger in using SVG files.

If you want to try what the million laughs attack (million circles in an SVG file) does to your browser, at your own risk, you can try https://www.nominal-animal.net/answers/this-tries-to-crash-your-browser.html or just the SVG image itself, https://www.nominal-animal.net/answers/this-tries-to-crash-your-browser.svg.
We can only hope browser developers add some run-time limits on how long they're willing to burn CPU time to render just a single image.

magic · « **Reply #19 on:** February 24, 2022, 09:06:35 am »

Yes, because you are embedding with <img> tags. If you open either file directly, the embedded MalwareScript starts to work

(There are also more dangerous embedding methods which were common in the past because browsers didn't support <img>).

I found a crude python script converting ASC to SVG. There is something not quite right with this file because different software displays it differently and neither is 100% right.
It does scale better, but 175KB - that would be a few megapixels in GIF

Quote from: Nominal Animal on February 24, 2022, 05:21:15 am

Compare to magic's GIF image, which on my display is quite mushy around the letters and quite blocky at the diagonal lines. It works, but isn't nice.

That's the LTspice renderer for you. None of that antialiasing rubbish.

Maybe the answer is to write a MalwareScript ASC renderer akin to MathJax. ASC shows itself to be a very efficient format for line drawings.

Nominal Animal · « **Reply #20 on:** February 24, 2022, 09:30:03 am »

Quote from: magic on February 24, 2022, 09:06:35 am

Yes, because you are embedding with <img> tags.

Well, that's the point of using SVG files instead of GIF/PNG/JPEG on a discussion forum, innit?

What we need, are browsers that are designed to work for users, instead of advertisers.

As is, Firefox only needs a timeout for cumulative maximum time per page load when rendering SVG images to its internal surfaces, and it would be robust against nefarious SVG files. Right now, a specifically crafted recursive SVG file can stop a page from being displayed, but I couldn't get it to crash.

I would say the abovelinked SVG attack surface report from Fortinet isn't exactly up to date.

magic · « **Reply #21 on:** February 24, 2022, 09:42:07 am »

I wonder if one could put a crypto miner in SVGs to monetize on those who open them in a new tab to take a closer look

Nominal Animal · « **Reply #22 on:** February 24, 2022, 10:07:26 am »

Quote from: magic on February 24, 2022, 09:42:07 am

I wonder if one could put a crypto miner in SVGs to monetize on those who open them in a new tab to take a closer look

A JavaScript one would work, but only if it did the heavy lifting in a timeout (otherwise the browser will kill the thread for consuming too much CPU time).

And, since the user would open the SVG file directly in their browser, they could also press Ctrl+U to see its source code, revealing the crypto miner also.

SVG images can by the way be compressed using gzip. It only requires that the server, when serving the compressed SVG file (.svgz), uses the "Content-Encoding: gzip" HTTP header. The browser then decompresses it while downloading, transparently, as it would e.g. static HTML and other files as well when gzip-encoded. On the client side, the SVG appears as normal non-gzipped file, too.

magic · « **Reply #23 on:** February 25, 2022, 08:35:58 am »

Or simply permit SVGZ uploads and keep SVG banned

BTW, screw mining, it's inefficient as hell. Do you think it would be possible to use AJAX code in SVG to change the viewer's forum email address and password bypassing CSRF protections and request ransom?

Nominal Animal · « **Reply #24 on:** February 25, 2022, 09:27:51 am »

Quote from: magic on February 25, 2022, 08:35:58 am

Do you think it would be possible to use AJAX code in SVG to change the viewer's forum email address

Using my browser, no.

What you can do, always, is create a lookalike phishing site. You can make that static, or dynamic. If you get the user to open an SVG image as a page, you can make the image look like a web page, with normal web page interactivity. If you display that SVG image in an <img element, my browser disables the interactivity; it is then just an "almost-realtime thumbnail" of that web page.

If you put a phishing site on your own server, you can work around cross-site request forgery protections, too. The idea is that part of your server acts like a reverse proxy for the target site (both Apache and Nginx support this out of the box). Then, the phishing site uses site-local URLs for those resources. If you pay someone at a certificate authority to give you a fake certificate for www.eevblog.com, you can do man-in-the-middle invisible phishing. Of course, this has nothing to do with SVG, and everything to do with how browsers handle security.

Which, by the way, hasn't really evolved at all in the last quarter century. We have IEEE 1363.2 and zero-knowledge password proof since 2008. Practical PAKE has existed as long as the web itself has. Password inputs are already special, and browsers have all the needed public-key cryptography stuff to implement these; nothing outside the user and the ZKPP facility actually needs access to the password field itself. But no, we instead get browser developer summits where after long deliberations, the key decision is "We declare every charset except UTF-8 to be legacy character sets. Because UTF-8 is not a legacy character set, users should not be able to select it as the default character set." and similar inanities.

magic · « **Reply #25 on:** February 25, 2022, 09:56:52 am »

No, I would put MalwareScript in the SVG which, when opened as an individual "image"

, downloads the account settings form from the forum, extracts CSRF cookies and submits the form filled with my email address. Then I reset your password.

Same Origin Policy shouldn't be a problem, I make requests to https://www.eevblog.com/ and thankfully attachments are also served from the same domain and over HTTPS

The last doubt I have is if XMLHttpRequest really permits downloading arbitrary URLs and submitting arbitrary POSTs, but it is my recollection that this is exactly what it does.

And none of it would show up on the thumbnail, of course, because MalwareScript is disabled in <img> mode

Zero999 · « **Reply #26 on:** February 25, 2022, 10:54:09 am »

Quote from: magic on February 23, 2022, 11:07:01 pm

BTW, I have no idea about real world efficiency of SVG. I mean, it's uncompressed XML so it cannot be great, but it's not a dumb bitmap format OTOH.

That being said, GIF isn't too bad either. Here's a real world schematic with almost 100 components in 32KB GIF.
https://www.eevblog.com/forum/projects/opamps-die-pictures/?action=dlattach;attach=1190312;image

Produced from the ASC vector format
The schematic is 16KB plus definitions of all the symbols (~500 bytes per symbol so maybe ~3KB total).

I guess SVG fanboys can upload something of comparable complexity to support their case

Why use colour? I converted that file to a monochrome PNG and it's now only 12.4kB.

Monochrome PNGs are a similar size, or sometimes smaller than ASC.

8-bit colour PNGs are normally smaller than GIFs. I generally use monochrome PNGs for schematics and those which do require colour are 8-bit, or less, which keeps the file size as small as possible.

I do like SVG and this has been mentioned before, but the consensus was it's too much of a security risk.

Nominal Animal · « **Reply #27 on:** February 25, 2022, 10:58:45 am »

Quote from: magic on February 25, 2022, 09:56:52 am

No, I would put MalwareScript in the SVG which, when opened as an individual "image"

As a page, you mean, instead of in an <img element. That would allow it to do stuff like XSS requests, yes.

Quote from: magic on February 25, 2022, 09:56:52 am

submits the form filled with my email address.

You forgot that the Account Settings page requires the current password (at the bottom) for exactly this reason!

(At least my browser requires actual user interaction to auto-fill it if saved as a login in the browser.)

Quote from: magic on February 25, 2022, 09:56:52 am

thankfully attachments are also served from the same domain and over HTTPS

You know, your and Ian.M's points have helped me realize a very important thing about online forums: they really should store all user attachments on a different domain. Not just for cross-site request vulnerabilities, but also because of server-side security considerations and resource use, things like how much CPU time may a single request consume before it is killed, when e.g. generating thumbnails. To me, this is very important, a new aspect of discussion forum security that I had not realized before. Thank you.

The obvious domain choice is to use dedicated subdomains, like forum.domain, attachments.domain, and auth.domain. The last one could be a solution to the problem I have with web hosting services –– they can provide only a single Unix account and group per site ––, essentially treating the problem of access to authentication information across the entire site, as a single-sign-on problem instead. That is, only auth.domain would ever have write access to the user account details, or any access to the privileged user information. (A fourth one, admin.domain, would help separate privileged administrative/moderation actions from normal operations in a similar way.) This would not only help with the server side scripting reliability – a script that does not have access to sensitive information cannot leak that sensitive information –, but also protect against cross-site attacks among subdomains.

If you have your own virtual server running Apache or Nginx, the configuration to support all on the same machine in different trees (and different Unix user accounts, to stop server-side script bugs exploiting direct filesystem access) is very simple; you can even make a group hierarchy that allows a "human" user to manage them all without sudo. You only need a single certificate, for *.domain, too.

magic · « **Reply #28 on:** February 25, 2022, 11:58:18 am »

Quote from: Nominal Animal on February 25, 2022, 10:58:45 am

You forgot that the Account Settings page requires the current password (at the bottom) for exactly this reason!

Damn, I missed it. But not all is lost

Since SVG can contain embedded HTML, we can put the whole SMF login page into it (again, not rendered in thumbnails) telling the sucker to log in again because some internal server error has occurred and session cookies have been lost or whatever

And of course, there are useful actions that don't require password. Like, everybody viewing my pics ends up thanking every one of my posts and PMing Dave to make me the official Designated SVG Expert of the forum

Quote from: Zero999 on February 25, 2022, 10:54:09 am

Monochrome PNGs are a similar size, or sometimes smaller than ASC.

8-bit colour PNGs are normally smaller than GIFs. I generally use monochrome PNGs for schematics and those which do require colour are 8-bit, or less, which keeps the file size as small as possible.

Interesting, I used GIF because I assumed that PNGs are 24 bit only. They always turned out larger for me. Will have to investigate.

duckduck · « **Reply #29 on:** August 03, 2022, 06:39:38 pm »

EEVBlog forum:

Quote

The only allowed extensions are doc,gif,jpg,jpeg,pdf,png,txt,zip,tar,c,h,hex,bas,xls,odt,asm,wav,aiff,wma,mp3,flac,asc,ods,xlsx,py,7z.

OK, so what about adding .webp?

From https://en.wikipedia.org/wiki/WebP :

Quote

On 18 November 2011, Google announced a new lossless compression mode, and support for transparency (alpha channel) in both lossless and lossy modes; support was enabled by default in libwebp 0.2.0 (16 August 2012).[14][15] According to Google's measurements in November 2011, a conversion from PNG to WebP resulted in a 45% reduction in file size when starting with PNGs found on the web, and a 28% reduction compared to PNGs that are recompressed with pngcrush and PNGOUT.[16]

In July 2016, Apple added WebP support to early beta versions of macOS Sierra and iOS 10,[17] but support was later removed in the GM seed versions of iOS 10 and macOS Sierra released in September 2016. In September 2020, WebP support was added in Safari version 14.[18]

The supporting libwebp library reached version 1.0 in April 2018.[19]

As of November 2021, web browsers that support WebP had 96% market share.[20]

Zero999 · « **Reply #30 on:** August 03, 2022, 09:53:12 pm »

Quote from: magic on February 25, 2022, 11:58:18 am

Quote from: Zero999 on February 25, 2022, 10:54:09 am
Monochrome PNGs are a similar size, or sometimes smaller than ASC.

8-bit colour PNGs are normally smaller than GIFs. I generally use monochrome PNGs for schematics and those which do require colour are 8-bit, or less, which keeps the file size as small as possible.
Interesting, I used GIF because I assumed that PNGs are 24 bit only. They always turned out larger for me. Will have to investigate.

Some software always saves as 24-bit PNG, which often makes the file larger than GIF. It's possible to get MS Paint to save as 1-bit PNG. Convert the image to monochrome by clicking on properties, note there's a bug which causes anything which isn't white to be changed to black, then save as .png. It's possible work around the, everything which isn't white will be black bug, by saving as monochrome .bmp first, then .png.

Proper imaging processing software such as Gimp is obviously the best way to go, as you chan save as 4-bit and 8-bit, as well as 1-bit and 24-bit.


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: Adding .svg to allowed attachment file types? (Read 5739 times)

Share me