http + ftp download plug-in

[CritterNYC]

Originally Posted by negativesir

Yes, this has to do with WM_INITDIALOG not returning false.

From MSDN:


Here is the fix for it, compiled in Visual C++ 6.0, tested on Windows 95.

Thanks, negativesir. I've verified that this fixes the issue with stealing focus and otherwise works unaltered. I wasn't sure if you'd compiled as release or debug back when you'd submitted this, so I recompiled it using a clean VC++6 under a clean Windows XP of release builds of both ANSI and Unicode just to be sure. It's now been updated on the inetc plugin download page.

[CritterNYC]

Originally Posted by negativesir

Here is the fix for it, compiled in Visual C++ 6.0, tested on Windows 95.

Thanks, negativesir! I've verified that this fixes the issues with stealing focus when in silent mode and does not affect other functionality. (for the curious an Abort was switched to return false where appropriate). I wasn't sure if you'd compiled as release or debug last year, so I recompiled using a clean VC++6 install on a clean Windows XP VM of the release config of both ANSI and Unicode. I've packaged it and updated the default download on the inetc plugins page.

[Afrow UK]

New version:

1.0.4.4 - 20th July 2014
* /tostack & /tostackconv added
* Version information resource added
* Updated to NSIS 3.0 plugin API
* Upgraded to Visual Studio 2012
* 64-bit build added
* MSVCRT dependency removed

Stu

[CritterNYC]

Re - 1.0.4.4: With the update to the NSIS 3.0 beta plugin API, does it still function the same for both NSIS Stable and NSIS Unicode?

[Anders]

Originally Posted by CritterNYC

Re - 1.0.4.4: With the update to the NSIS 3.0 beta plugin API, does it still function the same for both NSIS Stable and NSIS Unicode?

The plugin API has not changed since v2.43 so I'm not sure what Stu means by that comment.

[Afrow UK]

Sorry that change is misleading. The plug-in was using an old copy of exdll.h (with no myato* etc.). The actual API implementation hasn't changed; I have just updated the plugin API source code from latest.

Stu

[victoire]

Oh, so, I understand, thank you, that helped me a lot, thank you very much

------------------------------------------------------------------------

[victoire]

Thank you very much!

etui xperia z2

[PS22]

Thanks for the update, the /tostack flag is very useful. However, using the latest version of the plugin results in a lot of false positives from Antivirus software. Not a huge issue for me, just a heads up.

[PS22]

Update: the latest inetc.dll file is only being marked as a virus by Symantec. I contacted them and they whitelisted it in the latest definitions. But when you actively use the the plugin in your installer you seem to get a lot more false positives. (TrendMicro, VBA32, Kaspesky etc.)

[ghsatpute]

Hello,

I am trying to acces on HTTPS URL. I am getting "SendRequest Error".

I found one StackOverflow link.

This answer says set some flags and I have know idea how to do that

Does anybody know how to do this?

Regards,
Ganesh

[CritterNYC]

The StackOverFlow link is talking about that because the user is using a self-signed certificate. AKA, not from a certificate authority. As such, it'll be rejected and result in an error. If you're using a self-signed certificate, INETC won't work for you in its current form.

[joaosaleiro]

Hello,

I'm having a very weird problem with inetc::get that looks like a bug.
A very specific subset of our users are complaining that our installer doesn't work.

What's happening is that inetc::get is failing and it shows in the stack one of it's parameters.
For example, see the code below:

inetc::get /nocancel /translate "Downloading %s" "Connecting ..." second minute hour s "Checking version..." "" /caption " " "http://www.myserver.com/version.xml" "${UPDATES_DIR}\version.xml" /end
Pop $1

inetc::get /translate "Downloading %s" "Connecting ..." second minute hour s "Checking version..." "" /caption " " "http://www.myserver.com/version.xml" "$TEMP\version.xml" /end
Pop $2

inetc::get /noproxy /translate "Downloading %s" "Connecting ..." second minute hour s "Checking version..." "" /caption " " "http://www.myserver.com/version.xml" "${UPDATES_DIR}\version.xml" /end
Pop $3

inetc::get /noproxy /translate "Downloading %s" "Connecting ..." second minute hour s "Checking version..." "" /caption " " "https://www.myserver.com/version.xml" "${UPDATES_DIR}\version.xml" /end
Pop $4

inetc::get "https://www.myserver.com/version.xml" "${UPDATES_DIR}\version.xml" /end
Pop $5

MessageBox MB_OK "normal: $1 --> temp: $2 --> noproxy: $3 --> https: $4 --> noparams: $5 "


The result for this code is:

normal: /nocancel --> temp: /translate --> noproxy: /noproxy --> https: /noproxy --> noparams: https://www.myserver.com/version.xml

So, no matter the call, the error is always the first parameter used.
This doesn't happen with all users, and I haven't figured out what's so specific for those that get the error.

Can you please enlighten me? Is this a bug, or am I missing something?

Thanks!

JS

[Afrow UK]

Do you know what Windows version they are using?

Stu

[joaosaleiro]

I asked one of the users, and he's on Windows 7 professional x64 .

He stated also that he's not behind a proxy and he's using Bitdefender Plus 2015.

Does this help?

[apastel]

I am using Inetc to make some REST calls to a local Geoserver instance. I noticed that when performing an inetc:: put and supplying a header for content-type, that header is replaced with "Content-type octet-stream".

In other words, Inetc always assumes that I'm uploading a binary file; it will not let me do a put with something that isn't binary. I need to set the Content-type to something other than "octet-stream", and it doesn't seem like it can be done with the current implementation of Inetc.

I wrote a stackoverflow post on this issue and we were able to confirm what I've said in the source code. If the author is available to implement a fix, it would save me the trouble of having to call out to cURL or something to perform this portion of my install. I'd much rather use Inetc

Thank you

[joaosaleiro]

Hello,

on the 27th of November, I reported an issue with inetc::get . From that moment on, we've been having more and more users complaining that they cannot use the installer. The error they get is exactly what I reported here - http://forums.winamp.com/showpost.ph...&postcount=493
Can you please help me on this one? I don't really know what to do...

Thanks!

[Afrow UK]

Which version of the plug-in are you using? If you are using the latest, try an older one (the older builds were built using VC6).

http://nsis.sourceforge.net/File:Inetc.zip

Stu

[Afrow UK]

Originally Posted by apastel

I am using Inetc to make some REST calls to a local Geoserver instance. I noticed that when performing an inetc:: put and supplying a header for content-type, that header is replaced with "Content-type octet-stream".

In other words, Inetc always assumes that I'm uploading a binary file; it will not let me do a put with something that isn't binary. I need to set the Content-type to something other than "octet-stream", and it doesn't seem like it can be done with the current implementation of Inetc.

I wrote a stackoverflow post on this issue and we were able to confirm what I've said in the source code. If the author is available to implement a fix, it would save me the trouble of having to call out to cURL or something to perform this portion of my install. I'd much rather use Inetc

Thank you

So rather than replacing the existing header, you would like it to add only if it does not exist?

Stu

[joaosaleiro]

Hi Stu,

thanks for the tip! Unfortunately it didn't work. Here's more info:

• I compiled the installer with the build from 04:29, 20 August 2013
• Asked one of the users who reported the issue to test it
• He had the same problem I reported above - $1, $2, $3, etc are getting the parameters sent to inetc instead of the result of the call
• I asked him to try "running as administrator", and guess what... It worked fine!

Does this info provides any clue on what's happening?

Thanks!

JS

[Afrow UK]

Try building with the NSIS logging special build (you need to add LogSet on to your script). It sounds to me like the plug-in cannot be loaded under the original user for some reason.

Stu

[joaosaleiro]

Hi Stu,

thanks for the help.
I've sent the debug build to the client (with inetc from 04:29, 20 August 2013), who returned the results below.
It seems inetc.dll cannot be loaded. Any suggestions?

Starting Logger
CreateDirectory: "C:\Users\Hugo\AppData\Roaming\com.boonzi.desktop\Local Store\updates" (0)
Call: 152
File: overwriteflag=1, allowskipfilesflag=2, name="C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll"
File: wrote 20992 to "C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll"
Error registering DLL: Could not load C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll
Call: 152
File: overwriteflag=1, allowskipfilesflag=0, name="C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll"
File: skipped: "C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll" (overwriteflag=1)
Error registering DLL: Could not load C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll
Call: 152
File: overwriteflag=1, allowskipfilesflag=0, name="C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll"
File: skipped: "C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll" (overwriteflag=1)
Error registering DLL: Could not load C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll
Call: 152
File: overwriteflag=1, allowskipfilesflag=0, name="C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll"
File: skipped: "C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll" (overwriteflag=1)
Error registering DLL: Could not load C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll
Call: 152
File: overwriteflag=1, allowskipfilesflag=0, name="C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll"
File: skipped: "C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll" (overwriteflag=1)
Error registering DLL: Could not load C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll
MessageBox: 0,"normal: /nocancel --> temp: /translate --> noproxy: /noproxy --> https: /noproxy --> noparams: https://www.boonzi.com/server/releases/update "
MessageBox: 0,"Por favor, envie o ficheiro install.log para support@boonzi.com . Clique OK para abrir a pasta"
ExecShell: success ("open": file:"C:\Users\Hugo\AppData\Roaming\com.boonzi.desktop\app" params:"")
Delete: DeleteFile("C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll")
Delete: DeleteFile("C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\modern-header.bmp")
RMDir: RemoveDirectory("C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\")

[Afrow UK]

You should use Dependency Walker and open inetc.dll on the machine and check all the referenced DLLs exist. Also ask if they are using any antivirus or antimalware software which may be blocking the DLL.

Stu

[joaosaleiro]

Hi Stu,

thanks once again for the answer.
Most of these concepts are pretty new for me, so let's see if I understood correctly your suggestion:

1- I have to ask the end-user (with the problem) to download http://www.dependencywalker.com/
2- I have to send him the inetc.dll
3- I assume the dependency walker will return some kind of logging, that I have to ask the client to return to me, so I can paste it here.

Did I understand correctly?


Some of clients who had this issue had an anti-virus, but not all. Let me know if I got the steps right, so I can go forward and ask one of the users to try it out.

Thanks,

JS

[Anders]

Dependency walker should popup a messagebox when you open a dll if there is a problem. It also has a log window at the bottom that you should ask the user to copy, ignore warnings with "delay-load" in them...

[wd1]

Any application that uses inetc to download things from the internet can be attacked using man-in-the-middle (MITM) techniques. When inetc retrieves something over an https:// URI, the certificate is ignored, meaning that it could be downloading files from anywhere. The security impact of this goes as high as arbitrary code execution with administrative privileges.

[Anders]

Originally Posted by wd1

Any application that uses inetc to download things from the internet can be attacked using man-in-the-middle (MITM) techniques. When inetc retrieves something over an https:// URI, the certificate is ignored, meaning that it could be downloading files from anywhere. The security impact of this goes as high as arbitrary code execution with administrative privileges.

This is a good point and it should probably reject those connections by default and allow the script author to override it with a /nosecurity parameter or something like that...

[sgiusto]

Since sourceforge is down. Can you please post the plugin on this thread. I need it badly...

[JasonFriday13]

I checked the google cache, unfortunately the download link is still to sf.net. You can still browse the whole site via the cache.

[inst-user]

I'm using the Inetc plugin to download a large 3GB file and it displays a negative percent download. Is there any way I can fix this?

[simplix]

Hi everyone. More noticed that inetc not load files by https in WinXP, but without problems downloads it in Win7 and above.

[Anders]

Originally Posted by simplix

Hi everyone. More noticed that inetc not load files by https in WinXP, but without problems downloads it in Win7 and above.

INetC uses the WinINet API and XP is so old now that it does not support all the latest TLS/SSL crypto algorithms that some sites are using. There is a TLS setting in Internet Options that might help...

[Zam]

How do I FTP upload when the destination directory doesn't exist? I've tried the obvious thing, but that results in inetc::put getting stuck in an infinite loop.

Script is simple:

code:
RequestExecutionLevel user

outFile "ftptest.exe"

Section

	inetc::put "ftp://ftpserver//newdir/test.txt" "$EXEDIR\test.txt"

SectionEnd

"newdir" does not exist. When examining network traffic, I see this:

code:
STOR /newdir/test.txt

550 File cannot be created

MKD /newdir

257 "/newdir" created

MKD /newdir/test.txt

257 "/newdir/test.txt" created

MKD /newdir/test.txt/

257 "/newdir/test.txt/" created

MKD /newdir/test.txt//

etc. It keeps making that same request, adding another slash on the end each time until eventually the installer crashes.
If "newdir" already exists, then everything works as expected.

[DwayneVogler]

Is there likely to be a fix for the security vulnerability mentioned here?: http://www.kb.cert.org/vuls/id/894897

[Anders]

Originally Posted by DwayneVogler

Is there likely to be a fix for the security vulnerability mentioned here?: http://www.kb.cert.org/vuls/id/894897

Have you tried to contact the author of the plugin?

[DwayneVogler]

I assumed that the author would be watching this thread since this is linked in the download page for the plugin. Or that the community might know something since this is a few months old and high in my google results for "intetc".

[Anders]

I uploaded a new version, use /WeakSecurity to fall back to the old behavior.

I'll also attach a special test build here that tries to use binary mode when requesting the size over FTP.

[amalilith]

Small test case that reproduces the issue:

code:
OutFile "test-installer.exe"



Section

inetc::get "https://tibiamaps.github.io/tibia-map-data/Automap-with-markers.zip" "$pluginsdir\Automap.zip"

Pop $R0 ; Get the return value.

MessageBox MB_OK $R0

StrCmp $R0 "success" +3

  MessageBox MB_OK "Download failed; try again later."

  Quit

Pop $0

end:

SectionEnd

The first MessageBox shows just the capital letter “U”, which is not supposed to be one of the return values, right?

What am I doing wrong?

[Anders]

Originally Posted by amalilith

What am I doing wrong?

A single letter usually means you mismatched the plugins. Are you using the Unicode version of the plugin in a Ansi installer?

I would also recommend that you use the /END parameter at the end of that plugin function call!

[amalilith]

Originally Posted by Anders

A single letter usually means you mismatched the plugins. Are you using the Unicode version of the plugin in a Ansi installer?

I would also recommend that you use the /END parameter at the end of that plugin function call!

I was indeed using the wrong version of the plugin. Thanks for the help!