Wrong format of jpg message when adding jpg file

I have jpg file which is recognized as jpg by GIMP and other software packages. When I drag and drop it to be cover image of issue I got message that it is wrong file format.

However, its extension is .jpg

Please advise

Hi @vvucic,

See e.g. this FAQ entry. There are also other threads in the forum discussing how to resolve this; the best way to find them is to search the forum with the message OJS is giving you. (Please note which application you’re using, and what version, when you’re posting a question.)

Regards,
Alec Smecher
Public Knowledge Project Team

I am using OJS 3.0. U drag and drop file and it got green checkmark with obvious title of file1-1981-cover.jpg
When I click Save I got error message about wrong file format. I exported jpg file to png but I got the same error message agin.
Is that something on server may cause that?

Thanks

Hi @vvucic,

Is that something on server may cause that?

Yes, see the link I posted above.

Regards,
Alec Smecher
Public Knowledge Project Team

OK. I will ask hosting company support guys to check. But, what is interesting that when we insert images in editor for footer or other purposes that are displayed properly. I guess in those situations OJS does not use PHP mime content function.?

Thanks

Hello,
Administrator from the hosting company told me that I have to write mime_content_type function and include it where it is needed. Please suggest how to solve that issue.

Thanks,

Hi @vvucic,

I’m not totally clear what the hosting company is recommending – but OJS tries to use the Fileinfo suite of functions (e.g. finfo_open), which provide the modern PHP approach to checking file types. Does your host provide/support those functions?

Regards,
Alec Smecher
Public Knowledge Project Team

They told me that module is insecure and that they do not allow it on their servers. They told me if I can write that function and include it in OJS where it is needed.
Please advise

Hi @vvucic,

You’re referring to the mime_content_type function? OJS 3.0 doesn’t use that, so I’m not sure how it would cause the problem you describe.

Regards,
Alec Smecher
Public Knowledge Project Team

No, people from the hosting company are referring to finfo…

They say that such a module is insecure.

Thanks

Can you verify this with them again? I’m not aware of any security concerns with the finfo package.

They may mean that the application should fall back on mime_content_type() when finfo is unavailable, which I do think is reasonable.

Right now in master we go directly from the finfo call to a fallback of an external shell command to file.

I have received today mail from hosting company in which they infomed me that they do not enable fileinfo functions on shared hosting since that function is vulnerable.
I am also not aware of its vulnerability. But, I have read posts like this one:

or this
http://www.cvedetails.com/cve/CVE-2013-4636/

We decided to change hosting company. But, it could be good to consider inclusion of that function in OJS directly so OJS users should be more or less independent of such manners of hosting companies.

Thanks

I still disagree that the stated concern of fileinfo being insecure is valid, but the fallback to mime_content_type() is valid and we are working that into OJS 3.x:

I fully agree with you. Therefore we changed hosting company.
Btw. if you allow anyone to upload files security is very small since any abuse of trust can cause big harm.
Mentioning mp3 as a source of possible intrusion/DoS was not documented and we do not see whether mp3 was -prepared- to do harm or accidental.

Nevertheless, it could be good to have those relatively simple functions tbuilt in OJS so teh suers are not depndent on questionable knowledge of guys in hosting companies.

Thanks on comments

At the server level, it would be advisable to run an antivirus program (for example, clamav) to help to mitigate the risk of authorized users uploading a malicious file.

The file type identification within OJS is not intended to be a security measure - that really should be implemented on the server.

Indeed. I fully agree with you.

Thanks