[freenet-dev] Thoughts about Freenet deployment on Windows platforms.
Le 23/07/2013 16:07, Juiceman a ?crit : > Sent from my wireless phone. > On Jul 23, 2013 6:20 AM, "Matthew Toseland" > wrote: >> >> On Tuesday 23 Jul 2013 11:01:16 Matthew Toseland wrote: >>> On Monday 22 Jul 2013 11:47:17 Rom. wrote: Hello, I would like to expose some thoughts about the current move for the deployment of Freenet on windows platforms. Currently as far as i understand, toad and operhiem1 are the only to maintain the windows installer of Freenet. This Freenet installer and all Freenet EXE (freenet.exe, freenetlauncher.exe ) are written in AutoHotKey. Due to its limitations (Unicode support) and recurrent false positives from anti viruses, it has been considered to move away from > AutoHotKey. Toad summarize thoughts here: https://bugs.freenetproject.org/view.php?id=5456#c9883. After reading this, i have started (with curiosity in mind) to work on an installer written with InnoSetup (https://github.com/freenet/wininstaller-staging/issues/12), which is > a true and dedicated software for creating installer for Windows. >>> >>> Right. This looks promising. But during this process and with some previous experiences related to Freenet on windows (https://bitbucket.org/romnbb/freenetfortraveler) a question came to my mind: Does Freenet needs an installer on Windows ? What this installer currently does : - Check port availability and writing settings in freenet.ini file before its first launch. - Determine how much ram to allocate to java (wrapper.java.maxmemory) - Extract all Freenet related files What if Freenet package is provided as a Zip file (Toad post: https://bugs.freenetproject.org/view.php?id=5842) and all pre-required settings handled, at a "First launch step", by the main program on windows : Freenet.exe (aka Freenet Tray) ? Upsides: - A simple zip file can easily fits the maintainability requirement. Files that change the most are related to the core of freenet (freenet.jar, plugins and maybe others) not those related to windows. - There is no doubts or problems creating zip files natively from > Linux. >>> >>> How will antiviruses deal with it? Will the file insight type thingies > still complain about it because it's not a file they've seen before? Or > will they only look at the files inside it? If a zip file bypasses the need > to deal with this, it'd be sensible; if not, it probably makes more sense > to have a discrete installer. >>> >>> One thing we've been considering is uploading to the website a few days > after we've uploaded to auto-update. All nodes download the installer, so > the file will at least be "visible", although it won't have been run. We > could even run it, with some no-op flag, but that would probably be more > trouble than it's worth. Downsides: - Users need to know what to do with this Zip file. That, most > probably, why Installers are commonly used on Windows : user will click, click , click , click ... (without reading most of the time...) >>> >>> Right. It may make it a bit harder. Which is bad, and can only be > tolerated if it's offset by fewer problems with AV's. >>> - Handle of pre-settings must be ported to the main program > (freenet.exe). And with that come an other related question. If so, what to do about Freenet.exe (freenet tray), which is the > desktop interface between Users and Freenet main interface (freenet proxy). Keep using AutoHotKey ? Re-write it in another language (Java ? FreePascal ?). >>> >>> As far as AV's are concerned, AHK isn't ideal, but if they've seen the > file before they're less likely to complain about it; if these files are > updated infrequently, we can probably get away with it? Maybe i have missed some important things about this deployment on windows that can changed my thoughts if i am aware of. So, feedbacks are welcome. Whatever the direction taken, i will gladly help to maintain the > windows side of Freenet :) . >>> >>> Awesome! Best regards, Romain. PS: sorry if my english appears to be a bit "crude". It's not my > native language and long text doesn't help. >>> >>> Your english is fine above. >>> >> One other thing: For invites, we'd probably end up distributing a zip, > with some extra files, which the installer would recognise and deal with. >> >> So the big question is, will an AV always flag a foreign zip file, or > will it only concern itself with the executables inside that zip file? >> >> > > I 'think' most AV look at executable files. Exe, dll, pdf. Etc... > > Also some look at heuristics such as trying to install in the autorun > section of the Windows registry. If the installer platform is somewhat > mainstream it is easier. I have seen
[freenet-dev] Thoughts about Freenet deployment on Windows platforms.
Sent from my wireless phone. On Jul 23, 2013 6:20 AM, "Matthew Toseland" wrote: > > On Tuesday 23 Jul 2013 11:01:16 Matthew Toseland wrote: > > On Monday 22 Jul 2013 11:47:17 Rom. wrote: > > > Hello, > > > > > > I would like to expose some thoughts about the current move for the > > > deployment of Freenet on windows platforms. > > > > > > Currently as far as i understand, toad and operhiem1 are the only to > > > maintain the windows installer of Freenet. > > > This Freenet installer and all Freenet EXE (freenet.exe, > > > freenetlauncher.exe ) are written in AutoHotKey. > > > > > > Due to its limitations (Unicode support) and recurrent false positives > > > from anti viruses, it has been considered to move away from AutoHotKey. > > > Toad summarize thoughts here: > > > https://bugs.freenetproject.org/view.php?id=5456#c9883. > > > > > > After reading this, i have started (with curiosity in mind) to work on > > > an installer written with InnoSetup > > > (https://github.com/freenet/wininstaller-staging/issues/12), which is a > > > true and dedicated software for creating installer for Windows. > > > > Right. This looks promising. > > > > > > But during this process and with some previous experiences related to > > > Freenet on windows (https://bitbucket.org/romnbb/freenetfortraveler) a > > > question came to my mind: > > > > > > Does Freenet needs an installer on Windows ? > > > > > > What this installer currently does : > > > - Check port availability and writing settings in freenet.ini file > > > before its first launch. > > > - Determine how much ram to allocate to java (wrapper.java.maxmemory) > > > - Extract all Freenet related files > > > > > > What if Freenet package is provided as a Zip file > > > (Toad post: https://bugs.freenetproject.org/view.php?id=5842) and all > > > pre-required settings handled, at a "First launch step", by the main > > > program on windows : Freenet.exe (aka Freenet Tray) ? > > > > > > Upsides: > > > - A simple zip file can easily fits the maintainability requirement. > > > Files that change the most are related to the core of freenet > > > (freenet.jar, plugins and maybe others) not those related to windows. > > > - There is no doubts or problems creating zip files natively from Linux. > > > > How will antiviruses deal with it? Will the file insight type thingies still complain about it because it's not a file they've seen before? Or will they only look at the files inside it? If a zip file bypasses the need to deal with this, it'd be sensible; if not, it probably makes more sense to have a discrete installer. > > > > One thing we've been considering is uploading to the website a few days after we've uploaded to auto-update. All nodes download the installer, so the file will at least be "visible", although it won't have been run. We could even run it, with some no-op flag, but that would probably be more trouble than it's worth. > > > > > > Downsides: > > > - Users need to know what to do with this Zip file. That, most probably, > > > why Installers are commonly used on Windows : user will click, click , > > > click , click ... (without reading most of the time...) > > > > Right. It may make it a bit harder. Which is bad, and can only be tolerated if it's offset by fewer problems with AV's. > > > > > - Handle of pre-settings must be ported to the main program (freenet.exe). > > > > > > And with that come an other related question. > > > If so, what to do about Freenet.exe (freenet tray), which is the desktop > > > interface between Users and Freenet main interface (freenet proxy). > > > Keep using AutoHotKey ? Re-write it in another language (Java ? > > > FreePascal ?). > > > > As far as AV's are concerned, AHK isn't ideal, but if they've seen the file before they're less likely to complain about it; if these files are updated infrequently, we can probably get away with it? > > > > > > Maybe i have missed some important things about this deployment on > > > windows that can changed my thoughts if i am aware of. > > > > > > So, feedbacks are welcome. > > > > > > > > > Whatever the direction taken, i will gladly help to maintain the windows > > > side of Freenet :) . > > > > Awesome! > > > > > > Best regards, > > > Romain. > > > > > > > > > PS: sorry if my english appears to be a bit "crude". It's not my native > > > language and long text doesn't help. > > > > Your english is fine above. > > > One other thing: For invites, we'd probably end up distributing a zip, with some extra files, which the installer would recognise and deal with. > > So the big question is, will an AV always flag a foreign zip file, or will it only concern itself with the executables inside that zip file? > > I 'think' most AV look at executable files. Exe, dll, pdf. Etc... Also some look at heuristics such as trying to install in the autorun section of the Windows registry. If the installer platform is somewhat mainstream it is easier. I have seen InnoSetup before where as I had not seen ahk
Re: [freenet-dev] Thoughts about Freenet deployment on Windows platforms.
On Monday 22 Jul 2013 11:47:17 Rom. wrote: Hello, I would like to expose some thoughts about the current move for the deployment of Freenet on windows platforms. Currently as far as i understand, toad and operhiem1 are the only to maintain the windows installer of Freenet. This Freenet installer and all Freenet EXE (freenet.exe, freenetlauncher.exe ) are written in AutoHotKey. Due to its limitations (Unicode support) and recurrent false positives from anti viruses, it has been considered to move away from AutoHotKey. Toad summarize thoughts here: https://bugs.freenetproject.org/view.php?id=5456#c9883. After reading this, i have started (with curiosity in mind) to work on an installer written with InnoSetup (https://github.com/freenet/wininstaller-staging/issues/12), which is a true and dedicated software for creating installer for Windows. Right. This looks promising. But during this process and with some previous experiences related to Freenet on windows (https://bitbucket.org/romnbb/freenetfortraveler) a question came to my mind: Does Freenet needs an installer on Windows ? What this installer currently does : - Check port availability and writing settings in freenet.ini file before its first launch. - Determine how much ram to allocate to java (wrapper.java.maxmemory) - Extract all Freenet related files What if Freenet package is provided as a Zip file (Toad post: https://bugs.freenetproject.org/view.php?id=5842) and all pre-required settings handled, at a First launch step, by the main program on windows : Freenet.exe (aka Freenet Tray) ? Upsides: - A simple zip file can easily fits the maintainability requirement. Files that change the most are related to the core of freenet (freenet.jar, plugins and maybe others) not those related to windows. - There is no doubts or problems creating zip files natively from Linux. How will antiviruses deal with it? Will the file insight type thingies still complain about it because it's not a file they've seen before? Or will they only look at the files inside it? If a zip file bypasses the need to deal with this, it'd be sensible; if not, it probably makes more sense to have a discrete installer. One thing we've been considering is uploading to the website a few days after we've uploaded to auto-update. All nodes download the installer, so the file will at least be visible, although it won't have been run. We could even run it, with some no-op flag, but that would probably be more trouble than it's worth. Downsides: - Users need to know what to do with this Zip file. That, most probably, why Installers are commonly used on Windows : user will click, click , click , click ... (without reading most of the time...) Right. It may make it a bit harder. Which is bad, and can only be tolerated if it's offset by fewer problems with AV's. - Handle of pre-settings must be ported to the main program (freenet.exe). And with that come an other related question. If so, what to do about Freenet.exe (freenet tray), which is the desktop interface between Users and Freenet main interface (freenet proxy). Keep using AutoHotKey ? Re-write it in another language (Java ? FreePascal ?). As far as AV's are concerned, AHK isn't ideal, but if they've seen the file before they're less likely to complain about it; if these files are updated infrequently, we can probably get away with it? Maybe i have missed some important things about this deployment on windows that can changed my thoughts if i am aware of. So, feedbacks are welcome. Whatever the direction taken, i will gladly help to maintain the windows side of Freenet :) . Awesome! Best regards, Romain. PS: sorry if my english appears to be a bit crude. It's not my native language and long text doesn't help. Your english is fine above. signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Thoughts about Freenet deployment on Windows platforms.
On Tuesday 23 Jul 2013 11:01:16 Matthew Toseland wrote: On Monday 22 Jul 2013 11:47:17 Rom. wrote: Hello, I would like to expose some thoughts about the current move for the deployment of Freenet on windows platforms. Currently as far as i understand, toad and operhiem1 are the only to maintain the windows installer of Freenet. This Freenet installer and all Freenet EXE (freenet.exe, freenetlauncher.exe ) are written in AutoHotKey. Due to its limitations (Unicode support) and recurrent false positives from anti viruses, it has been considered to move away from AutoHotKey. Toad summarize thoughts here: https://bugs.freenetproject.org/view.php?id=5456#c9883. After reading this, i have started (with curiosity in mind) to work on an installer written with InnoSetup (https://github.com/freenet/wininstaller-staging/issues/12), which is a true and dedicated software for creating installer for Windows. Right. This looks promising. But during this process and with some previous experiences related to Freenet on windows (https://bitbucket.org/romnbb/freenetfortraveler) a question came to my mind: Does Freenet needs an installer on Windows ? What this installer currently does : - Check port availability and writing settings in freenet.ini file before its first launch. - Determine how much ram to allocate to java (wrapper.java.maxmemory) - Extract all Freenet related files What if Freenet package is provided as a Zip file (Toad post: https://bugs.freenetproject.org/view.php?id=5842) and all pre-required settings handled, at a First launch step, by the main program on windows : Freenet.exe (aka Freenet Tray) ? Upsides: - A simple zip file can easily fits the maintainability requirement. Files that change the most are related to the core of freenet (freenet.jar, plugins and maybe others) not those related to windows. - There is no doubts or problems creating zip files natively from Linux. How will antiviruses deal with it? Will the file insight type thingies still complain about it because it's not a file they've seen before? Or will they only look at the files inside it? If a zip file bypasses the need to deal with this, it'd be sensible; if not, it probably makes more sense to have a discrete installer. One thing we've been considering is uploading to the website a few days after we've uploaded to auto-update. All nodes download the installer, so the file will at least be visible, although it won't have been run. We could even run it, with some no-op flag, but that would probably be more trouble than it's worth. Downsides: - Users need to know what to do with this Zip file. That, most probably, why Installers are commonly used on Windows : user will click, click , click , click ... (without reading most of the time...) Right. It may make it a bit harder. Which is bad, and can only be tolerated if it's offset by fewer problems with AV's. - Handle of pre-settings must be ported to the main program (freenet.exe). And with that come an other related question. If so, what to do about Freenet.exe (freenet tray), which is the desktop interface between Users and Freenet main interface (freenet proxy). Keep using AutoHotKey ? Re-write it in another language (Java ? FreePascal ?). As far as AV's are concerned, AHK isn't ideal, but if they've seen the file before they're less likely to complain about it; if these files are updated infrequently, we can probably get away with it? Maybe i have missed some important things about this deployment on windows that can changed my thoughts if i am aware of. So, feedbacks are welcome. Whatever the direction taken, i will gladly help to maintain the windows side of Freenet :) . Awesome! Best regards, Romain. PS: sorry if my english appears to be a bit crude. It's not my native language and long text doesn't help. Your english is fine above. One other thing: For invites, we'd probably end up distributing a zip, with some extra files, which the installer would recognise and deal with. So the big question is, will an AV always flag a foreign zip file, or will it only concern itself with the executables inside that zip file? signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Thoughts about Freenet deployment on Windows platforms.
On Tuesday 23 Jul 2013 16:56:03 Rom. wrote: AV's are capable of reading inside zip (and probably other common archives). Hence, if freenet.exe is flagged, the archive will probably be flagged too. I have some doubts about the fact that if AV's have seen the file before they will be less susceptible to complain. It's more a deal with file patterns (and heuristics, like juiceman said). As AutoHotKey Exes contain the script interpreter, which is a common pattern (and this pattern appears in true malwares written in AHK). But AV's behavior seems to be erratic for this point. Both are true. Most modern AV's will complain on files that they haven't seen before. For example, a recent user gave up when he got this: http://www.symantec.com/security_response/writeup.jsp?docid=2010-051308-1854-99 It's a good idea in principle - especially if the file has been substituted, it may even has a bogus signature, which is very hard to detect as there are so many SSL providers. It's an even better idea if like Freenet it's not signed at all - we can fix that though. Some reading if you are interested (a bit old, but still regularly true) : AutoIt : http://www.autoitscript.com/forum/topic/34658-are-my-autoit-exes-really-infected/ AutoHotKey: http://www.donationcoder.com/forum/index.php?topic=15210.0 AutoHotKey: http://www.autohotkey.com/board/topic/29203-an-open-letter-for-antiviral-software-companies/ That looks like what we've been seeing so far. :( signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Thoughts about Freenet deployment on Windows platforms.
Hello, I would like to expose some thoughts about the current move for the deployment of Freenet on windows platforms. Currently as far as i understand, toad and operhiem1 are the only to maintain the windows installer of Freenet. This Freenet installer and all Freenet EXE (freenet.exe, freenetlauncher.exe ) are written in AutoHotKey. Due to its limitations (Unicode support) and recurrent false positives from anti viruses, it has been considered to move away from AutoHotKey. Toad summarize thoughts here: https://bugs.freenetproject.org/view.php?id=5456#c9883. After reading this, i have started (with curiosity in mind) to work on an installer written with InnoSetup (https://github.com/freenet/wininstaller-staging/issues/12), which is a true and dedicated software for creating installer for Windows. But during this process and with some previous experiences related to Freenet on windows (https://bitbucket.org/romnbb/freenetfortraveler) a question came to my mind: Does Freenet needs an installer on Windows ? What this installer currently does : - Check port availability and writing settings in freenet.ini file before its first launch. - Determine how much ram to allocate to java (wrapper.java.maxmemory) - Extract all Freenet related files What if Freenet package is provided as a Zip file (Toad post: https://bugs.freenetproject.org/view.php?id=5842) and all pre-required settings handled, at a "First launch step", by the main program on windows : Freenet.exe (aka Freenet Tray) ? Upsides: - A simple zip file can easily fits the maintainability requirement. Files that change the most are related to the core of freenet (freenet.jar, plugins and maybe others) not those related to windows. - There is no doubts or problems creating zip files natively from Linux. Downsides: - Users need to know what to do with this Zip file. That, most probably, why Installers are commonly used on Windows : user will click, click , click , click ... (without reading most of the time...) - Handle of pre-settings must be ported to the main program (freenet.exe). And with that come an other related question. If so, what to do about Freenet.exe (freenet tray), which is the desktop interface between Users and Freenet main interface (freenet proxy). Keep using AutoHotKey ? Re-write it in another language (Java ? FreePascal ?). Maybe i have missed some important things about this deployment on windows that can changed my thoughts if i am aware of. So, feedbacks are welcome. Whatever the direction taken, i will gladly help to maintain the windows side of Freenet :) . Best regards, Romain. PS: sorry if my english appears to be a bit "crude". It's not my native language and long text doesn't help.
