Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 15 18:06
    GitLab | Greg Slepak pushed 3 commits to Group Income - Simple
  • Jun 15 18:06
    GitLab | Greg Slepak pushed 1 commits to Group Income - Simple
  • Jun 15 18:05
    GitLab | Greg Slepak pushed 1 commits to Group Income - Simple
  • Jun 13 17:36
    GitLab | Greg Slepak pushed 1 commits to Group Income - Simple
  • Jun 11 17:44
    GitLab | Greg Slepak pushed 4 commits to Group Income - Simple
  • Apr 11 02:46
    GitLab | Greg Slepak pushed 1 commits to Group Income - Simple
  • Apr 08 22:41
    GitLab | Greg Slepak pushed 6 commits to Group Income - Simple
  • Jan 21 18:28
    GitLab | Greg Slepak pushed 3 commits to Group Income - Simple
  • Jan 20 03:25
    GitLab | Greg Slepak pushed 4 commits to Group Income - Simple
  • Jan 20 02:26
    GitLab | Greg Slepak pushed 1 commits to Group Income - Simple
  • Jan 20 02:26
    GitLab | Greg Slepak pushed 1 commits to Group Income - Simple
  • Jan 03 23:53
    GitLab | Greg Slepak pushed 1 commits to Group Income - Simple
  • Jan 02 23:51
    GitLab | Greg Slepak pushed 11 commits to Group Income - Simple
  • Dec 05 2020 20:01
    GitLab | Greg Slepak pushed 4 commits to Group Income - Simple
  • Dec 03 2020 21:47
    GitLab | Greg Slepak pushed 1 commits to Group Income - Simple
  • Dec 01 2020 02:08
    GitLab | Greg Slepak pushed 2 commits to Group Income - Simple
  • Nov 30 2020 21:03
    GitLab | Greg Slepak pushed 3 commits to Group Income - Simple
  • Nov 17 2020 22:40
    GitLab | Greg Slepak pushed 2 commits to Group Income - Simple
  • Nov 09 2020 18:13
    GitLab | Greg Slepak pushed 1 commits to Group Income - Simple
  • Oct 17 2020 22:16
    GitLab | Greg Slepak pushed 1 commits to Group Income - Simple
slack-relay
@slack-relay
<Geometric Algorithm> @greg Roger.
slack-relay
@slack-relay
<Snowteamer> @greg Yea it's a bit more complicated than initially expected, however the main bottleneck is probably that I didn't have much time
<Snowteamer> Today I've updated my PR, hopefully those nasty XSS should be gone!
<Snowteamer> However I think it is still possible to insert anchor tags with malicious hrefs, since I had to allow them for our own anchor tags to render properly 😕
slack-relay
@slack-relay

<greg> @Snowteamer

So now hopefully those nasty XSS should be gone!
Awesome! 😄 👍

However I think it is still possible to insert anchor tags with malicious hrefs, since I had to allow them for our own anchor tags to render properly
Of course we want to ensure that we get rid of all known potential XSS and not knowingly allow some through. If the concern is something like href="javascript:, then can you:

  1. Find an example XSS that still makes it past (to use as testing)
  2. Use either whitelisting or blacklisting to fix?
    I recommend first starting with whitelisting, as that's stronger protection. Here's what I mean by that: have a look at all of the uses of href that we make use of with i18n, and create a pattern-based whitelist. For example, if you notice that we have 2 types of links that we use with href, e.g. href="http...." and href="#anchor", then you can create a regex based whitelist using that (e.g. check if the string starts ^ with either http or #), and only allow those through.

Is that a way forward that makes sense to you?

slack-relay
@slack-relay

<Snowteamer> Not sure if a regex can be comprehensive enough to provably defeat every clever way to bypass it. Between escaping, encoding, browser bugs and so on, there are so many possibilities, as can be seen in https://owasp.org/www-community/xss-filter-evasion-cheatsheet

Couldn't we instead refactor some of our Vue and/or Pug code to no longer dynamically insert anchor tags, but to have them hardcoded as part of the markup ?
If so, then we could simply disallow them in the sanitizer config.

slack-relay
@slack-relay

<greg> @Snowteamer

Couldn't we instead refactor some of our Vue and/or Pug code to no longer dynamically insert anchor tags, but to have them hardcoded as part of the markup ?If so, then we could simply disallow them in the sanitizer config.
Good idea. If you can find all such instances and rewrite them while preserving functionality, go for it. If you run into problems with the rewrite, or have questions, let us know here.

<greg> nice link 👍
<Snowteamer> 😄
slack-relay
@slack-relay

<greg> <@U01DQ4JGH9A> gave me this as another HW assignment in a DM.

I'm re-posting it here so that others can comment as well with their thoughts on what the distribution should be.: https://files.slack.com/files-pri/T02K87MKW-F022ZLTQ65U/download/untitled

<greg> My question is (copied):

Regarding this part (sorry for the formatting, Slack is broken at copy/pasting):
it('EVENT: a payment of $10 is made from u1 to u3. u1 then switches their haveNeed to -10.', function () { setup = setup.concat([ { type: 'paymentEvent', data: { from: 'u1', to: 'u3', amount: 10, when: dateAtCyclesPassed(cycle += 0.1) } }, { type: 'haveNeedEvent', data: { name: 'u1', haveNeed: -10, when: dateAtCyclesPassed(cycle += 0.1) } } ]) should(groupIncomeDistributionWrapper(setup, { adjusted: true, minimizeTxns: false, mincomeAmount })).eql([ { amount: 6.666666666666666, from: 'u2', to: 'u1' }, { amount: 13.333333333333332, from: 'u2', to: 'u3' } ]) should(groupIncomeDistributionWrapper(setup, { adjusted: false, minimizeTxns: false, mincomeAmount })).eql([ { amount: 6.666666666666666, from: 'u2', to: 'u1' }, { amount: 13.333333333333332, from: 'u2', to: 'u3' } ]) })
It seems to me like there should be two payments for $10 each from u2, right? Since both u1 and u3 need $10 each, and there's $20 to cover. Am I missing something?

slack-relay
@slack-relay
slack-relay
@slack-relay
<greg> Summary of Chat:
  • Greg: Make it clear what the technical writer position is for + Finishing & publish Bulgaria Hackathon + Working on e2e stuff + e2e hiring
  • Catarina: Sharing job listing on social media (Twitter & Mastodon) + Finishing social media strategy
  • Leihla: Go through Github issues + features for prototype + Give Pierre feedback when ready
  • Pierre: Leihla's additions in animation video
  • Andrea: Funding wiki + Finances page
  • Ian: "Fix bug when people who receive or make payments switch to being a haver or needer, and then make a payment, and then switch back"
  • Snowteamer: finishing up PR

<greg> ✅ Make it clear what the technical writer position is for

Improved this job description a bit: https://groupincome.org/pos-technical-writer/

slack-relay
@slack-relay

<greg> Catarina did a great job on sharing the job listings, feel free to share via whatever means you’d like:

• https://twitter.com/group_income/status/1400118945936560128
• https://mstdn.io/@GroupIncome/106342064437734176

slack-relay
@slack-relay
<greg> ✅ Pushed a final draft of the Bulgaria hackathon post to Gitlab (see #blog), reviews / feedback welcome!
slack-relay
@slack-relay
<greg> Got some code started on the e2e stuff 🙂
<greg> Am beginning work on the SBP api
slack-relay
@slack-relay
slack-relay
@slack-relay
<greg> Summary of Chat:
  • Greg: Working on e2e stuff + Publish Bulgaria Hackathon
  • Catarina: Working with tshirt company on samples + Social media posts/strategy
  • Pierre: Leihla's additions in animation video
  • Leihla: Creating new screens for all settings (group settings & profiles settings)
  • Andrea: Funding wiki + Finances page
  • Ian: Fix bug when people who receive or make payments switch to being a haver or needer, and then make a payment, and then switch back
  • Snowteamer: finishing up PR
slack-relay
@slack-relay

<Snowteamer> Hello, I'm currently trying to get the UI working unmodified with a tags disallowed in the dompurify config, but I'm not really experienced with Vue and Pug, so I'm not sure about the best way to refactor those i18n instances containing anchor links.

It seems to require splitting the i18n text content into up to three parts (for the text before, inside, and after the link), which is less convenient for translators than a single sentence.

Also, I'm bothered by not seeing how to statically detect a tag insertion into i18n component instances, since they can be dynamically passed through arguments. A linter rule could catch some cases but not absolutely everything, and this could confuse developers trying to insert a tags into i18n text since the anchor won't be rendered.

slack-relay
@slack-relay

<greg> @Snowteamer

It seems to require splitting the i18n text content into up to three parts (for the text before, inside, and after the link), which is less convenient for translators than a single sentence.
Yes, it's definitely important to keep it as a single sentence for the translators, good observation. 👍

Also, I'm bothered by not seeing how to statically detect a tag insertion into i18n component instances, since they can be dynamically passed through arguments. A linter rule could catch some cases but not absolutely everything, and this could confuse developers trying to insert a tags into i18n text since the anchor won't be rendered.
Maybe you can share some examples of what you're referring to?

And also some examples of the particular lines of code that you'd like help converting? The more you share about what it is you're looking at and the problems you're running in to, the more context either I or @Pierre or others will have to maybe offer some suggestions

slack-relay
@slack-relay

<Snowteamer> For example in AppLogs.vue, the i18n element generated by the following code, which embeds a GitHub issue page link:

Pug:
p.c-instructions(v-safe-html='instructions')

JS:
instructions () { const errorMsg = this.$route.query.errorMsg const linkTag = { 'a_': '<a class="link" target="_blank" href="https://github.com/okTurtles/group-income-simple/issues">', '_a': '</a>' } return errorMsg ? L('Recent error: "{errorMsg}". Please download the logs and {a_}send them to us{_a}, so we can help troubleshoot.', { errorMsg, ...linkTag }) : L('If you encounter problems, please download the logs and {a_}send them to us{_a}.', linkTag) }

<Snowteamer> This link is perfectly safe, but will be nonetheless wiped if a tags are not allowed.
slack-relay
@slack-relay

<Snowteamer> Meanwhile I've come up with an idea - keep embedded a links forbidden, but implement and allow our own link component e.g. gi-safe-link which could be embedded in i18n text without causing safety issues with href .

The key differences between this link component and v-safe-link from GitLab UI being that
• it wouldn't use href as argument name since we'd still disallow it, but a name which has no significance in regular HTML so it can be whitelisted too.
• it wouldn't accept any custom URL which we don't own, but only URLs from a hardcoded whitelist (e.g. Group Income's issue page, blog page, etc).
• a set of constants could be defined to identify those URLs, to avoid typing URLs, e.g. ISSUE_PAGE.
Is this a viable approach?

slack-relay
@slack-relay
<greg> @Snowteamer I think so. I’ll think on it some more and will let you know if I see any issues, in the meantime feel free to try that approach!
slack-relay
@slack-relay

<greg> ✅ Bulgaria Hackathon post published!

• Tweet: https://twitter.com/Group_Income/status/1402280744236449803
• Toot: https://mstdn.io/@GroupIncome/106375721478427096

slack-relay
@slack-relay
<greg> Worked some more today on API for the e2e stuff and the framework. Not entirely sure what to call it. https://gitlab.okturtles.org/okturtles/group-income-simple/-/wikis/E2E-Protocol/Framework.md
slack-relay
@slack-relay
<greg> FYI am adding a new feature to SBP — the ability for domains/namespaces to have a state that can be accessed via this, and initialized (similar to a constructor) using a special &lt;domain&gt;/_init selector that gets called upon registration of the domain: https://files.slack.com/files-pri/T02K87MKW-F0248GJVBP1/download/screen_shot_2021-06-10_at_10.21.05_am.png
<greg> The state for the domain is the same across all selectors of that domain, making it easy to share state across different selectors
slack-relay
@slack-relay

<Snowteamer> As a nitpick, I would say that if it can have method, it looks more like a local API.

If every SBP domain can have its own local API, then I think its structure and type definition should be fully discoverable by only reading _init() source code.

Therefore other code should not be allowed to change that API by adding, removing, or replacing members. This could be achieved by using Object.freeze() on this immediately after _init() has run.

Of course other code must still be able to mutate domain data, just not change the domain's API. For example in the chelonia domain, it makes sense to add new entries to this.contracts but not to redefine this.contracts property itself.

slack-relay
@slack-relay
<greg> @Snowteamer I'm not entirely sure I understand what you're saying and what you mean by "local API". I don't think it's possible to freeze this, since it gets rebound each time the selector is called. I see no problem with other selectors in the same domain being able to modify and add new entries to the local state of the domain.
slack-relay
@slack-relay
<greg> Made some good progress today moving over the Contract.js file into the framework
<greg> Am executing on a plan for creating an API that allows sending different types of OPs to the contracts
slack-relay
@slack-relay

<Snowteamer> @greg By "local API" I meant the properties and methods of the given SBP domain. So indeed the _init() works like a constructor for the domain. Usually, when other code tries adding new properties to such an object after it has been constructed, the type system will complain because that would change the object's shape (aka its type) and cause various issues.

However, Flowtype might not be able to do that with SBP domain objects if they are defined as generic plain objects.
Therefore we would have to prevent domain object shape changes ourselves.

<greg> OK, maybe that's something we can look into after I submit my PR. AFAICT, neither flow nor typescript will be able to tell the type because the this will be dynamically bound on each invocation
<greg> (via .call)
slack-relay
@slack-relay
<Snowteamer> Ok, that's fine. 👍
<Snowteamer> For my part regarding issue #975, I made a bit of progress by setting up two different sanitization configs for i18n translation and v-safe-html directive
slack-relay
@slack-relay
<greg> Awesome! 👍
<Snowteamer> Thank you 😄
slack-relay
@slack-relay
<greg> Made more progress today on the new framework API and migration, lots of files are gonna be touched (basically anything that involves creating and sending GIMessages)
slack-relay
@slack-relay
slack-relay
@slack-relay
<greg> Summary of Chat:
  • Greg: Working on e2e stuff + Review Catarina's "Board View" plan
  • Catarina: Adding content to monthly plan + Posting job listings with rewritten copy + Contacting tshirt company
  • Pierre: Website & some time off
  • Andrea: Sharing results of Ian's homework with him + posting job listings + review Catarina's marketing plan
  • Leihla: Chat with Greg on future designs for new features + Creating new screens for all settings (group settings & profiles settings)
  • Ian: Fix bug when people who receive or make payments switch to being a haver or needer, and then make a payment, and then switch back
  • Snowteamer: finishing up PR
slack-relay
@slack-relay
<greg> Something I am working on today is moving all GIMessage creations that are outside of the actions/ folder into the appropriate files within that folder. For group related actions, I have so far moved 2, and have about 15 or 16 left to move (some of them are no longer used, e.g. Mailbox.vue). Once those are all moved, the next step is to convert them to using the new <framework>/out/actionEncrypted API for creating and sending actions in one go
<greg> Some of these actually don't require moving, just updating. E.g. 'gi.contract/group/paymentUpdate/create' in PaymentRowSent.vue just needs to be converted to 'gi.actions/group/paymentUpdate'
slack-relay
@slack-relay
<greg> I have to say, this app is starting to really come together in a very well organized, clean way
slack-relay
@slack-relay
<greg> Finished moving all of the GIMessage creations into the actions/ folder, and solidified / upgraded the framework API. Next step is to finish converting all of the actions to using the new API, and then moving on to implementing the key operations for the e2e stuff
<greg> Progress in #dev