VBA Rubberducking

> Anything you do to "make the VBA code secure" will be defeated within seconds by anyone that wants to "get in": putting a password on the VBA code is about as secure as locking your screen door - it keeps the bugs out, but if that's the best you've got any burglar is going to pee their pants in laughter as they cut through the screen like a hot knife in butter.

Hosch250

@MathieuGuindon You mean if I put a password on my VBA code, it won't have bugs anymore?

Mathieu Guindon

yup. that's exactly what I said. </nope>

IvenBach

Nope. The password keeps them from getting in.

Hosch250

@IvenBach Right.

I password-protect it, then start writing code.

Thanks for the clarification.

IvenBach

6:38 PM

Duck check: Is Range().FormulaR1C1 = "foo" the default for the macro recorder? I would have sworn it's Value.

Mathieu Guindon

you password-protect it, then you can't write the code. so you unprotect it. then re-protect it for distribution. then unprotect again to make a bugfix, re-protect to release the bugfix. #PITA

IvenBach

Have I just become so used to using .Value that I've convinced myself?

@MathieuGuindon That's why you include your password with the file... Duh. Make it easier when you need to unlock it next time.</joke>

Mathieu Guindon

@IvenBach by making it FormulaR1C1 the recorder doesn't need to tell whether you've entered a formula or not - it'll "just work"

@IvenBach might as well

IvenBach

@MathieuGuindon That's the default I'm getting on several computers. Is that how it's always been?

Mathieu Guindon

I'd think so.

mansellan

6:43 PM

There's this... spreadsheet1.com/… Works by deleting all the p-code from the workbook, leaving just the compiled code. Trouble is, if you open the workbook on a different architecture, it has to recompile. Which it can't do, because some fool deleted all the p-code... /facepalm.

IvenBach

6:54 PM

That strikes me as an XY problem solution.

Duga

[rubberduck-vba/Rubberduck] mansellan commented on Rubberduck.VBEEditor/SafeComWrappers/VB/Enums/VBEKind.cs of pull request #4098: VB6 - Do not delete source files during attributes parse

FreeMan

7:25 PM

@mansellan "[5] The converted file can only be run in the same PC and in the Excel (or PowerPoint) version used for its compilation. " "can only be run in the same PC" So... what you're doing is protecting it from yourself.

this

@mansellan FWIW, removing the p-code was the most logical thing they could have done to enable protection of the source code. In Access' case, you do have to have the .accdb file, then build the .accde on 32-bit Access, then again on 64-bit Access, then distribute the respective .accdes. There basically is no Any CPU setting.

@FreeMan In Access' case, an .accde compiled in Access 2010 32-bit can be opened by any other Access 32-bit versions equal or later than 2010; the same file would be unopenable in an Access 2007.

But the real problem, IMO, is the references. A VBA project embeds the full path to each library. Therefore, if they are not the same on the target computer....

FreeMan

@this Maybe that's just a language thing, then where "same PC" actually means same OS version & bitness

this

which makes anything that relies on external library (a common candidate is the common control library for example) fragile. If one PC has a different version of the mscomctl.ocx than another PC, then....

It should. At least I'd hope that is how they'd implement that technique for Excel/PowerPoint.

(never used it, so can't say if it's implemented the same way it is w/ .accde.

Duga

[rubberduck-vba/Rubberduck] bclothier commented on Rubberduck.VBEEditor/SafeComWrappers/VB/Enums/VBEKind.cs of pull request #4098: VB6 - Do not delete source files during attributes parse

mansellan

@this Yep I agree its about the only thing possible. I just wouldn't want to work somewhere that had to use it. Pain, pain and more pain...

this

7:38 PM

Hey, that's why I like my belts and suspenders!

and overalls.

and coveralls.

and overcoats.

and umbrellas.

mansellan

Heh, if/when RD gets plugins we could probably eat their lunch...

FreeMan

7:54 PM

@this don't forget the long-johns

Mathieu Guindon

lol, would love to see their face when RD uses the typelibs api to populate the code explorer

mansellan

@MathieuGuindon lol :-)

Mathieu Guindon

> It looks like procedure DoSomething is missing its VBA source code. Would you like Rubberduck to reverse-compile the P-Code into VBA source?

jaw drops

actually, the VBE does that all the time... whenever a line is typed in

source VBA -> p-code -> "pretty-print" -> editor

IIUC

this

well, there's 7 levels or so

FreeMan

@MathieuGuindon LOL

this

8:01 PM

and if I remember, only 3 of those are to do w/ source code; 4 with the actual p-code. Pretty printing need not go that deep.

Hosch250

@MathieuGuindon Now we are getting deep into black-hat territory ;)

this

Not necessarily. That can be still be white-hat.

Hosch250

First place, I was just kidding. Second, who doesn't want to be a black-hat?

this

The lost & found hasn't gotten back to me when I reported about my sense of humor.

Hosch250

@this :)

mansellan

8:03 PM

Iiuc, whats left is close to what vb6 emits when targetting native. Tricky to decompile, symbols are lost.

Hosch250

@mansellan Yep. It's probably optimized, potentially inlined...

this

@mansellan hm, they should always have source files.... Else, they are probably hacking someone else's work?

Mathieu Guindon

right

Hosch250

Hence my black-hat comment.

If someone took the trouble to destroy that, they probably don't want it re-revealed.

this

IDK if that's generally true but for .accde w/o source files, the story is usually "we had a guy doing access stuff years ago and he left and we kept on using this project but now we need to upgrade and all we have is .accde"

Mathieu Guindon

8:06 PM

^

but if the best you get is obfuscated VBA code, I'd rather not

this

For VB6 (and general purpose languages), the story is usually different

I don't know how many people use VB6 in-house compared to commerically?

Mathieu Guindon

fewer than yesterday, more than tomorrow

FreeMan

^ true dat!

this

@MathieuGuindon here's a sample of what Wayne can extract: everythingaccess.com/mdeconversion_example.htm

Mathieu Guindon

holy crap

this

8:09 PM

That's apparently because of "compiler junk" that gets embedded. Hence his other product: everythingaccess.com/mdeprotector_example.htm

Mathieu Guindon

IOW, the tooling already exists and we have no business there

also VBA code is insecure, full stop

this

hm. how is that different from .NET assembly, though?

Hosch250

CIL?

this

We can decompile a .NET assembly more easily than decompile a p-code removed VBA project.

(assuming no obfuscator was used)

Mathieu Guindon

it's not

this

8:14 PM

so the argument that VBA code is insecure doesn't hold weight?

it's more like, they didn't provide the tooling for securing it for all types of VBA projects.

Mathieu Guindon

it's as insecure as any other code? the thing is that VS doesn't give you a "password-protect your project" illusion of security

this

oh yes, password protect is a big joke

and should have never existed.

hm. does VB6 have that?

Mathieu Guindon

I don't think so

this

but beyond that, it's just as insecure as a .NET assembly, the difference that it'll be harder to find a decompiler for VBA compared to one for decompiler. IIRC, there is only one that ThunderFrame mentioned whereas there are more than few choices for .NET assemblies.

If it's really that sensitive, it should be never on an end user's computer to start with.

Mathieu Guindon

^

if you don't want to leak your code, don't leak your code.

Hosch250

8:19 PM

Alternatively, you can hire an intern to write the code for you. Nobody'll ever be able to make heads or tails of it.

2

It'll have so many security flaws, an attacker won't know where to start :P

this

Great, Hosch! But will it actually work?!? :o

Hosch250

@this As long as you don't look at it sideways.

M.Doerner

Really, from an actual security standpoint it is rather irrelevant whether you can look at the code.

It might be from a business standpoint though.

Hosch250

@M.Doerner Very irrelevant, although it can sometimes help find flaws.

On the other hand, it might obscure flaws because you look too much at the code and don't hit it enough in different ways.

M.Doerner

I know, but you can decompile next to everything to find the commonly problematic portions of code. It just takes more effort.

^Yep, that is why widely used OSS software is considered rather secure.

There are so many poeple that already tried to break it.

this

8:28 PM

Well, OpenSSL did have a bug that nobody noticed for months....

M.Doerner

True

this

Hopefully that was just a anomaly -- people were genuinely shocked by the fact that the bug existed for so long

M.Doerner

At least someone found it in the code and notified the maintainers.

this

almost a year?

yes

M.Doerner

Most low level software has stupid bugs like that.

That is why the OSS usually protects you against quite a large variaty of common threats.

Btw, regarding the rewriter and the busy state, I think this will get rather annoying to work with, if we cannot just hand out the rewriter itself and simply suspend while it is held by somone else.

I would know a way to achieve that, but that would be quite a hack.

Hosch250

8:33 PM

@M.Doerner OTOH, *nix systems have been having the most bugs reported per year by security researchers--because all the attackers focused on Windows for so long, it was effectually open-sourcing finding attacks.

this

OK, alright. I just wanted to keep the implementation simple as possible. If we encumber the contributor with "should do"s, it becomes annoying and bug-prone as well.

M.Doerner

To be honest, I did not really understand your suggestion. Where would that delegate go?

this

let me find an example first

M.Doerner

OK

@Hosch250 That is the point, You want people reporting the bugs to find them so that you can patch them before other poeple exploit them.

Hosch250

Right. But just because the code is OSS doesn't mean it is more secure than closed source software.

this

8:42 PM

so let's use this as an example: github.com/rubberduck-vba/Rubberduck/blob/next/…

what I envisioned would be something similar to this....

        private void PromoteVariable(IModuleRewriter rewriter, Declaration target)
        {
            if (new[] { DeclarationType.ClassModule, DeclarationType.ProceduralModule }.Contains(target.ParentDeclaration.DeclarationType))
            {
                _messageBox.NotifyWarn(RubberduckUI.PromoteVariable_InvalidSelection, RubberduckUI.IntroduceParameter_Caption);
                return;
            }

            var oldSelection = _vbe.GetActiveSelection();

            rewriter.Rewrite(() =>

basically, whenever we use any methods on the Rewriter, it has to be enclosed in Rewrite so that we abstract the suspension logic away from the refactoring/quick fixes

However, I realized that this is not easy to use if we have multiple rewriters as is the case in the MoveCloserToUsage refactoring.

This is also assuming that we must require that the suspension lock be held when we specify tokens to remove/add/whatever else. I don't know if that is a valid assumption.

M.Doerner

9:05 PM

Now, I get the idea. The TokenSourceparameter was throwing me off.

I think it might be more intuitive though to pass an Action<IModuleRewriter>.

Moreover, the first thing done inside the suspension should always be to check whether the rewriter is still the current one.

ANyway, I think this can wait for a later PR.

this

that makes sense yeah - but how do we ensure that all rewriter's methods stay encapsulated inside the action?

Yes I agree that is best done in later PR. I have no plans to do this right now; I just want to finish the busy PR so I can finish the refactoring PR.

and then hopefully get around to the EM. (ha, ha, ha)

Hosch250

@this Going to tell them your sense of humor is leaking?

this

hmm maybe I should tell them that it's radioactive and cancer-forming. Maybe they'll give it back in a hurry?

Duga

9:35 PM

[rubberduck-vba/Rubberduck] mansellan commented on Rubberduck.VBEEditor/ISourceCodeHandler.cs of pull request #4098: VB6 - Do not delete source files during attributes parse

[rubberduck-vba/Rubberduck] mansellan synchronized pull request #4098: VB6 - Do not delete source files during attributes parse

[rubberduck-vba/Rubberduck] [codecov[bot]](github.com/apps/codecov) edited comment on pull request #4098: VB6 - Do not delete source files during attributes parse

> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4098?src=pr&el=h1) Report
> Merging [#4098](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4098?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/c5bb40f9981a7e759da7009d9a6d11a73aa9099b?src=pr&el=desc) will **increase** coverage by `<.01%`.
> The diff coverage is `22.58%`.

```diff
@@ Coverage Diff @@
## next #4098 +/- ##
=======================

[rubberduck-vba/Rubberduck] [codecov[bot]](github.com/apps/codecov) edited comment on pull request #4098: VB6 - Do not delete source files during attributes parse

> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4098?src=pr&el=h1) Report
> Merging [#4098](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4098?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/c5bb40f9981a7e759da7009d9a6d11a73aa9099b?src=pr&el=desc) will **increase** coverage by `<.01%`.
> The diff coverage is `22.58%`.

```diff
@@ Coverage Diff @@
## next #4098 +/- ##
=======================

[rubberduck-vba/Rubberduck] mansellan commented on Rubberduck.VBEEditor/ISourceCodeHandler.cs of pull request #4098: VB6 - Do not delete source files during attributes parse

Duga

9:57 PM

[rubberduck-vba/Rubberduck] build for commit a6cdf6b2 on unknown branch: AppVeyor build succeeded

[rubberduck-vba/Rubberduck] [codecov[bot]](github.com/apps/codecov) edited comment on pull request #4098: VB6 - Do not delete source files during attributes parse

> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4098?src=pr&el=h1) Report
> Merging [#4098](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4098?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/c5bb40f9981a7e759da7009d9a6d11a73aa9099b?src=pr&el=desc) will **increase** coverage by `<.01%`.
> The diff coverage is `22.58%`.

```diff
@@ Coverage Diff @@
## next #4098 +/- ##
=======================

[rubberduck-vba/Rubberduck] build for commit a6cdf6b2 on unknown branch: 52.63% (target 0%)

Duga

10:15 PM

[rubberduck-vba/Rubberduck] mansellan created comment on issue #3995: VB6 VBForm parse errors

> Valid shortcut keys are:

^[A-Z]
{F[1-12]}
^{F[1-12]}
+{F[1-12]}
+^{F[1-12]}
^{INSERT}
+{INSERT}
{DEL}
+{DEL}
%{BKSP}

IvenBach

I now see why nobody likes writing documentation.

Writing good documentation is hard.

this

there is that, but I also think the real killer is the maintenance.

IvenBach

Thankfully I don't have to worry about that.

I'm just trying to write baby step examples on how to use VBA for Excel.

this

@M.Doerner can you clarify the #3 and #5 in the busy PR? They seem to be say to do the exact opposite? #3 says to add a lock (which we already have a write lock) while #5 says to remove it?

M.Doerner

I mean a separate ordinary lock on a separate lock object.

Not the same lock the actual suspension uses.

Its use is make sure that the suspension marker cannot change while in the if block.

Duga

10:26 PM

[rubberduck-vba/Rubberduck] mansellan synchronized pull request #4098: VB6 - Do not delete source files during attributes parse

[rubberduck-vba/Rubberduck] [codecov[bot]](github.com/apps/codecov) edited comment on pull request #4098: VB6 - Do not delete source files during attributes parse

> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4098?src=pr&el=h1) Report
> Merging [#4098](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4098?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/38be73730ae7a05dcca540a83c1c029fc6505fb0?src=pr&el=desc) will **decrease** coverage by `0.02%`.
> The diff coverage is `16%`.

```diff
@@ Coverage Diff @@
## next #4098 +/- ##
==========================

M.Doerner

You do not want to still be in that block when the TryPop happens.

this

and just so I know I'm clear when you speak of "suspension marker", we mean _supsenionIteration, right?

M.Doerner

Yes

this

good

Duga

[rubberduck-vba/Rubberduck] build for commit 49b04cfa on unknown branch: AppVeyor build succeeded

[rubberduck-vba/Rubberduck] [codecov[bot]](github.com/apps/codecov) edited comment on pull request #4098: VB6 - Do not delete source files during attributes parse

> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4098?src=pr&el=h1) Report
> Merging [#4098](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4098?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/38be73730ae7a05dcca540a83c1c029fc6505fb0?src=pr&el=desc) will **decrease** coverage by `0.02%`.
> The diff coverage is `16%`.

```diff
@@ Coverage Diff @@
## next #4098 +/- ##
==========================

[rubberduck-vba/Rubberduck] build for commit 49b04cfa on unknown branch: 52.63% (target 0%)

this

10:43 PM

now that if we have an ordinary lock around the _suspensionIteration and _requestorStack, does it makes the use of InterLocked moot?

M.Doerner

11:48 PM

I think it does.

Duga

[rubberduck-vba/Rubberduck] mansellan added label PR-Status: WIP to pull request #4111: VB6 - Add missing VBForm grammar cases

[rubberduck-vba/Rubberduck] mansellan added label PR-Status: Review Requested to pull request #4111: VB6 - Add missing VBForm grammar cases

M.Doerner

Moreover, since the access for adding to the stack is now excluive and the separated from poping the stack and clearing it because of the two locks, an ordinary stack would suffice, too.

Duga

[rubberduck-vba/Rubberduck] mansellan review_requested pull request #4111: VB6 - Add missing VBForm grammar cases

[rubberduck-vba/Rubberduck] mansellan created pull request #4111: VB6 - Add missing VBForm grammar cases to merge mansellan/Rubberduck/3995 into rubberduck-vba/Rubberduck/next

> First attempt #3995.

Not ready to merge, PR'ing now to get some feedback.

[rubberduck-vba/Rubberduck] mansellan review_requested pull request #4111: VB6 - Add missing VBForm grammar cases

this

FYI - I could not see a reason to separate the try/finally block.

mansellan

@Duga @this @M.Doerner would appreciate your feedback when you get a chance. My grammar-fu is... limited.

this

11:52 PM

I did move the code around so that both separate locks for setting the marker & popping the lock happen inside the try block

the logic for checking whether reparse is needed is still outside the write lock (and the 2 locks), since we use local variables to bring forward the results discovered from actions inside the new lock inside the write lock.

Mathieu Guindon

So they moved the modem downstairs... now I gotta make the wire subtly get into the garage without ruining the living room

mansellan

could you not use a powerline adapter?

Mathieu Guindon

?

I mean the ethernet cable

mansellan

these things

amazon.co.uk/TL-PA4010KIT-Powerline-Configuration-Required-UK/…

(that's UK version ofc, assume they have similar in canada)

sends ethernet frames over mains wiring