User talk:Anonymous31415927: Difference between revisions

From Rosetta Code
Content added Content deleted
mNo edit summary
(*sigh*)
 
(8 intermediate revisions by 4 users not shown)
Line 1: Line 1:
== jpegs ==
About 99 bottles of beer:


You have started to repeat posting this block of text in the discussion on matrix with two diagonals:
1. <<Most people solving this task iterate from 99 to 0. But 2, 1 and 0 are special cases, thus they write conditional expressions to split the flow control. '''This lead to weird codes'''. [...] Compared to '''hackish''' "not hard coded" '''spagetti''' examples (in Python) below>>


<div style="margin-left: 30px">
This is your opinion. You are free to think as you want, but I don't think you should put it in a wiki.
-- '''Sorry to say, childs, but dangerous-JPEG is an old urban legend.''' The https://www.cvedetails.com/cve/CVE-2004-0200 was in 2004 and was caused by '''a bug in MS Windows''' (GDI+), not that it was JPEG. But I understand - '''some people's ass is on fire because they are afraid of exploits from 2004.''' I would advise you to drink a glass of water, switch from MS Windows 98 to MS Windows 11, install all updates and anti-virus program other than Kaspersky. And take the pills prescribed by your doctor regularly.


Likewise, Samantha virus was not a de facto JPEG file, it only pretended to be one. Which was only possible because a few of the less clever MS programmers thought they had a good idea of ​​hiding the file extension from users.
2. this solutions is [...] 4. easy for i18n and l10n; 5. open to extensions


'''In fact, every link - and even the image of the Rosseta stone displayed on the Rosseta Code website - could be ... oh yo oh ah - terrible and terrible CVE. Fear and terror, terror and hiccups. We should all be dead.'''
Functional simplified version is much more simple for i18n. Furthermore, how can a script be "open to extensions"? On the contrary, functional versions are extended per se, since you can put everything, not only 99, not only bottle(s) of beer, not only on the wall, etcetera. And they are much more funny.


'''But every day we somehow open thousands of jpegs on websites and we live? Strange isn't it?'''
If you want a real extendable version, you have to write a module or a class. An overkill IMHO for the task.
</div>


&gt;&gt;&gt;I have been removing it for several reasons:
Can you please remove the considerations that can only start a flame war?


The civilized way of '''discusing is not to erase''' what others write, but to make factual arguments. It's nice '''you finally understand that.'''
[[User:Marco Sulla|Marco Sulla]] ([[User talk:Marco Sulla|talk]]) 17:07, 19 January 2020 (UTC)

: Making factual arguments is certainly a better option than erasing non-factual arguments. But that does not excuse making non-factual arguments. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 08:01, 7 March 2022 (UTC)

'''I am against jpegs on RC website.''' Really. Not because they are technically dangerous in any way. But because - if they are on an external server - RC cannot be sure that they will not be replaced with one that will show content not accepted by RC.

: Ok, that sounds like a valid concern. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 08:01, 7 March 2022 (UTC)

&gt;&gt;&gt;# The 2004 thing was not the only example of this buffer overflow problem -- it's something that keeps happening, so

Of course, mistakes, errors of various kinds, can be dangerous. Once upon a time (about 1/3 century ago) '''it was enough to write an e-mail''' subject string long enough to overflow the buffer and so on. '''Should we stop using e-mail''' for this reason?

Your reasoning is that of '''a driver who completely drunk got into a car with broken brakes, no airbags, no seat belts, and blames a tree by the road for the accident.''' Well, actually - if that tree wasn't there, it wouldn't be able to break down on that particular tree. Fact!

: I think you exaggerate here. Worse, you confuse things I did not say with things I did say, while ignoring what it was that I was saying --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 08:01, 7 March 2022 (UTC)

If the program is badly written, running on a crap system (without memory protection), the sandbox does not work and the buffer is overwritten by crafted jpeg ... then '''don't say jpeg is a devil's invention, but just patch the real holes in your system.''' The jpeg format as such has no scripts, it is not an executable format.

: Of course, I did not say any such thing. But "jpeg is an executable format" was never the issue. Instead, the problem is that vulnerable jpeg decoders have been a recurring problem. And, despite this, you were saying that that problem had not been happening. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 08:01, 7 March 2022 (UTC)

&gt;&gt;&gt;# Suggesting that there's no historical validity to being cautious about image links is the wrong approach, and

A simple question that you probably don't know the answer to: '''how is a link to an image (jpeg) different from a link to anything else?''' By demonizing the harmfulness of jpegs, you don't notice the obvious.

: Actually, I am quite aware of the harmfulness not only of other links, but of various non-url issues. But that does not mean it's valid to say that the jpeg buffer overflow problems never happened. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 08:01, 7 March 2022 (UTC)

&gt;&gt;&gt;# There are people who actively go out and try to deal with people taking advantage of buffer overflow problems, which means the problems tend to be relatively rare, so a lack of examples isn't particularly meaningful (especially when you ignore well documented examples of jpeg buffer over problems which are more recent than 2004),

There are all kinds of bad people in this world. However, '''spreading panic is unnecessary''' and will not lead to anything. Embedding malware into jpeg? For what? Since attacks can be done more simply and effectively in a thousand other ways?!

: Sure, and I have been on the receiving end of some of that. But that doesn't make the jpeg related problems urban legend. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 08:01, 7 March 2022 (UTC)

&gt;&gt;&gt;# Minimizing external dependencies on a website is generally good practice anyways,

Yes, it is true. See above why I am against externally hosted jpegs.

&gt;&gt;&gt;so being "too cautious" in this context seems like a maybe mediocre but not horrible and maybe even good idea. (Certainly a lot better than some of the other stunts people have been pulling, recently.)

&gt;&gt;&gt;Now, ... it's undoubtedly true that some people somewhere discourage image links because they have been annoyed by porn. But that does not seem relevant here, since that's not the kind of image under discussion.

'''I have met many times people who said that "jpeg infected their system".''' 99% of the time it was actually an attack ... while (coincidence) they were viewing pictures that were '''completely harmless files.''' 1% are naïve who considered the virus that deleted their files (jpeg files were zero length after the attack) to be a virus that "sits in jpeg". Punny.

: Most problems are, indeed, self inflicted. But, not all. And, I have also encountered plenty of people claiming that such things never happen (also, without any evidence). Anyways.. *you* were first suggesting that the jpeg buffer overflow problems had not happened. And then, when I pointed at some evidence to the contrary, you were suggesting that the jpeg buffer overflow problems had not happened since then. And then when I pointed at some evidence to the contrary you ignored that evidence and simply restated that they had not been happening. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 08:01, 7 March 2022 (UTC)

In order to infect a computer with jpeg, you need a lot of knowledge, skills and you can do it when the system is vulnerable (ie not updated since 2004).

: *Somebody* needs to have knowledge and skills. But programs -- including programs which can trigger bugs in other programs -- can be used by someone other than the person who wrote them. And you know this. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 08:01, 7 March 2022 (UTC)

In order to put eg a photo [...] someone does not need any knowledge or special skills. It swallows any system, even with the latest patches.

Latest revision as of 08:01, 7 March 2022

jpegs

You have started to repeat posting this block of text in the discussion on matrix with two diagonals:

-- Sorry to say, childs, but dangerous-JPEG is an old urban legend. The https://www.cvedetails.com/cve/CVE-2004-0200 was in 2004 and was caused by a bug in MS Windows (GDI+), not that it was JPEG. But I understand - some people's ass is on fire because they are afraid of exploits from 2004. I would advise you to drink a glass of water, switch from MS Windows 98 to MS Windows 11, install all updates and anti-virus program other than Kaspersky. And take the pills prescribed by your doctor regularly.

Likewise, Samantha virus was not a de facto JPEG file, it only pretended to be one. Which was only possible because a few of the less clever MS programmers thought they had a good idea of ​​hiding the file extension from users.

In fact, every link - and even the image of the Rosseta stone displayed on the Rosseta Code website - could be ... oh yo oh ah - terrible and terrible CVE. Fear and terror, terror and hiccups. We should all be dead.

But every day we somehow open thousands of jpegs on websites and we live? Strange isn't it?

>>>I have been removing it for several reasons:

The civilized way of discusing is not to erase what others write, but to make factual arguments. It's nice you finally understand that.

Making factual arguments is certainly a better option than erasing non-factual arguments. But that does not excuse making non-factual arguments. --Rdm (talk) 08:01, 7 March 2022 (UTC)

I am against jpegs on RC website. Really. Not because they are technically dangerous in any way. But because - if they are on an external server - RC cannot be sure that they will not be replaced with one that will show content not accepted by RC.

Ok, that sounds like a valid concern. --Rdm (talk) 08:01, 7 March 2022 (UTC)

>>># The 2004 thing was not the only example of this buffer overflow problem -- it's something that keeps happening, so

Of course, mistakes, errors of various kinds, can be dangerous. Once upon a time (about 1/3 century ago) it was enough to write an e-mail subject string long enough to overflow the buffer and so on. Should we stop using e-mail for this reason?

Your reasoning is that of a driver who completely drunk got into a car with broken brakes, no airbags, no seat belts, and blames a tree by the road for the accident. Well, actually - if that tree wasn't there, it wouldn't be able to break down on that particular tree. Fact!

I think you exaggerate here. Worse, you confuse things I did not say with things I did say, while ignoring what it was that I was saying --Rdm (talk) 08:01, 7 March 2022 (UTC)

If the program is badly written, running on a crap system (without memory protection), the sandbox does not work and the buffer is overwritten by crafted jpeg ... then don't say jpeg is a devil's invention, but just patch the real holes in your system. The jpeg format as such has no scripts, it is not an executable format.

Of course, I did not say any such thing. But "jpeg is an executable format" was never the issue. Instead, the problem is that vulnerable jpeg decoders have been a recurring problem. And, despite this, you were saying that that problem had not been happening. --Rdm (talk) 08:01, 7 March 2022 (UTC)

>>># Suggesting that there's no historical validity to being cautious about image links is the wrong approach, and

A simple question that you probably don't know the answer to: how is a link to an image (jpeg) different from a link to anything else? By demonizing the harmfulness of jpegs, you don't notice the obvious.

Actually, I am quite aware of the harmfulness not only of other links, but of various non-url issues. But that does not mean it's valid to say that the jpeg buffer overflow problems never happened. --Rdm (talk) 08:01, 7 March 2022 (UTC)

>>># There are people who actively go out and try to deal with people taking advantage of buffer overflow problems, which means the problems tend to be relatively rare, so a lack of examples isn't particularly meaningful (especially when you ignore well documented examples of jpeg buffer over problems which are more recent than 2004),

There are all kinds of bad people in this world. However, spreading panic is unnecessary and will not lead to anything. Embedding malware into jpeg? For what? Since attacks can be done more simply and effectively in a thousand other ways?!

Sure, and I have been on the receiving end of some of that. But that doesn't make the jpeg related problems urban legend. --Rdm (talk) 08:01, 7 March 2022 (UTC)

>>># Minimizing external dependencies on a website is generally good practice anyways,

Yes, it is true. See above why I am against externally hosted jpegs.

>>>so being "too cautious" in this context seems like a maybe mediocre but not horrible and maybe even good idea. (Certainly a lot better than some of the other stunts people have been pulling, recently.)

>>>Now, ... it's undoubtedly true that some people somewhere discourage image links because they have been annoyed by porn. But that does not seem relevant here, since that's not the kind of image under discussion.

I have met many times people who said that "jpeg infected their system". 99% of the time it was actually an attack ... while (coincidence) they were viewing pictures that were completely harmless files. 1% are naïve who considered the virus that deleted their files (jpeg files were zero length after the attack) to be a virus that "sits in jpeg". Punny.

Most problems are, indeed, self inflicted. But, not all. And, I have also encountered plenty of people claiming that such things never happen (also, without any evidence). Anyways.. *you* were first suggesting that the jpeg buffer overflow problems had not happened. And then, when I pointed at some evidence to the contrary, you were suggesting that the jpeg buffer overflow problems had not happened since then. And then when I pointed at some evidence to the contrary you ignored that evidence and simply restated that they had not been happening. --Rdm (talk) 08:01, 7 March 2022 (UTC)

In order to infect a computer with jpeg, you need a lot of knowledge, skills and you can do it when the system is vulnerable (ie not updated since 2004).

*Somebody* needs to have knowledge and skills. But programs -- including programs which can trigger bugs in other programs -- can be used by someone other than the person who wrote them. And you know this. --Rdm (talk) 08:01, 7 March 2022 (UTC)

In order to put eg a photo [...] someone does not need any knowledge or special skills. It swallows any system, even with the latest patches.