NO

Author Topic: Addin's management  (Read 361 times)

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 1654
Addin's management
« on: August 10, 2018, 04:58:11 pm »
I'm not sure this is exactly a bug, but something is strange in addins management.
All files present in the AddIns/AddIns64 are treated as addins independently from the file extension.
I.e. renaming the addin 'debug.dll' to 'debug.whatever' the IDE still load extensions and run them.
Deleting completely the files they still appear in the IDE customization dialog. You must close and reopen the IDE to have them removed.
As I said this is not technically a bug, but developing an addin sometime can be useful to rename the former working version to test the new one, but in that case the IDE loads it 2 times (the former and the newer version).

Offline TimoVJL

  • Global Moderator
  • Member
  • *****
  • Posts: 1745
Re: Addin's management
« Reply #1 on: August 11, 2018, 11:16:47 am »
The poide collect *.dll to Add-Ins list.
If i unload Add-In and rename or delete it, i can't load it again.
It don't show version info from a renamed dll.

I use Sysinternals Process Monitor to see what happens.

EDIT: tests was done using poide -xml option, not with register.
« Last Edit: August 12, 2018, 01:43:40 pm by TimoVJL »
May the source be with you

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 1654
Re: Addin's management
« Reply #2 on: August 11, 2018, 05:00:53 pm »
Try this with Win10 and PellesC 9.0:
- open explorer and navigate to addins directory with PellesC IDE open
- Rename one of active addins dll to something else (i.e. rename 'buildver.dll' to 'buildver.dll-dont use')
  You should not be allowed to change name to a running DLL, but you can.
- Close IDE
- Reopen IDE and check addins, it is still there loaded and runing.
- If you open and close the IDE nothing changes.
- If you try to delete the DLL file while poide is running the system refuses to delete it.
- Close the IDE and delete the DLL then restart the IDE.
- Only after file deletion it is no more loaded.

Another thing that I'm not sure is correct is how the IDE behaves with freshly added addins. The new addins are activated by default. So a defective or harmful addin will start immediately after poide launch.
This make also difficult to follow the eventual debug of addin under development.
« Last Edit: August 11, 2018, 05:46:59 pm by frankie »

Offline Pelle

  • Administrator
  • Member
  • *****
  • Posts: 1962
    • http://www.smorgasbordet.com
Re: Addin's management
« Reply #3 on: August 18, 2018, 07:58:19 pm »
1. Version 9.0 is 64-bit only, so it's just the addins64 directory that is relevant (the addin directory is never used).
2. The file scan is for *.dll, so renaming the file means it won't be found.
3. It appears that Windows 10 allows a file loaded through LoadLibrary() to be renamed. Maybe it has everything loaded in memory. Anyway, nothing I can change.
4. There is special support in the IDE for debugging an add-in, using a second copy of the IDE where only the debuggee DLL is loaded. This is the recommened practice, not (mis-)using the production directory addins64. Only copy to addins64 once the add-in is properly debugged.
5. Yes, as of 9.0 add-ins are activated by default. This is a huge improvement IMO.

Bottom line: I can't reproduce, and I see no obvious problems here...
/Pelle

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 1654
Re: Addin's management
« Reply #4 on: August 19, 2018, 12:45:12 am »
2. The file scan is for *.dll, so renaming the file means it won't be found.
3. It appears that Windows 10 allows a file loaded through LoadLibrary() to be renamed. Maybe it has everything loaded in memory. Anyway, nothing I can change.
In fact it seems as system file recovery service. I'll check in new OS features.  >:(

4. There is special support in the IDE for debugging an add-in, using a second copy of the IDE where only the debuggee DLL is loaded. This is the recommened practice, not (mis-)using the production directory addins64. Only copy to addins64 once the add-in is properly debugged.
Fantastic  :D. I haven't found info in the help. where may I found info?

5. Yes, as of 9.0 add-ins are activated by default. This is a huge improvement IMO.
I think that this is a security hole. It could be good to have an addin starting on itself, but if the addin has been put there by malicious code it will run freely.
It is very different if the user activate the addin, at least he/her knows that what code has been activated.
Moreover special addins, i.e. the build version updater, could alter the user code leading to strange problems.
Of course a security hole has always been there caused by the IDE calling the main addin function in the DLL...  :(

Offline Pelle

  • Administrator
  • Member
  • *****
  • Posts: 1962
    • http://www.smorgasbordet.com
Re: Addin's management
« Reply #5 on: August 19, 2018, 08:59:37 pm »
Fantastic  :D. I haven't found info in the help. where may I found info?
It's either a super-secret feature or I forgot to write something about it. Take a pick...  ;)

EDIT: There is a sentence in "IDE: General project options dialog" under "Executable helper for DLL projects", but it was hard to find so I will add something to "Projects: Debugging projects".

I think that this is a security hole. It could be good to have an addin starting on itself, but if the addin has been put there by malicious code it will run freely.
It is very different if the user activate the addin, at least he/her knows that what code has been activated.
Moreover special addins, i.e. the build version updater, could alter the user code leading to strange problems.
Of course a security hole has always been there caused by the IDE calling the main addin function in the DLL...  :(
Well, normally the installation is somewhere under "Program Files" with some protection from Windows. It's hard to see how a DLL-file, with a rather specific entry-point, can suddenly turn up here without you giving it permission to do so (through manual copy or by running a Setup program). Untrusted add-in files should never reach AddIns64, what happens after that should matter less (and yes, the build version updater is an oddball that never should have been written, but removing it now is problematic too).
« Last Edit: August 19, 2018, 09:11:41 pm by Pelle »
/Pelle

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 1654
Re: Addin's management
« Reply #6 on: August 20, 2018, 11:03:34 pm »
It's either a super-secret feature or I forgot to write something about it. Take a pick...  ;)

EDIT: There is a sentence in "IDE: General project options dialog" under "Executable helper for DLL projects", but it was hard to find so I will add something to "Projects: Debugging projects".
Well, it seems a very good idea, especially because ... I still couldn't locate it  :P
Maybe it's because it's late, but I hade to search the help file for the sentence "IDE: General project options dialog???

Well, normally the installation is somewhere under "Program Files" with some protection from Windows. It's hard to see how a DLL-file, with a rather specific entry-point, can suddenly turn up here without you giving it permission to do so (through manual copy or by running a Setup program)
...
Well to trust OS is as to trust a wolf for a shepherd ...   ::)
Anyway IMHO if the user knows what he's activating is better.  ;)

Anyway thanks
« Last Edit: August 20, 2018, 11:07:59 pm by frankie »