Editor stays editable after opening a locked file in read only mode

Describe the bug
When you open a locked file and accept the dialog for opening it in read only mode, the editor stays editable.
But the internal byte provider itself switches to read only mode. This results in confusing behavior.
When you attempt to save changes, it looks like the changes are saved, but they are not.
To Reproduce

Start sample application
Open locked file
Accept dialog for opening the file in read only mode
Make any changes
Save the file

Expected behavior
After opening locked file, the editor switches to read only mode and prevents modifications.
Desktop
OS: Windows 10
Platform: .NET Core 3.1

I check this at end of day :)
Thank you @Filipsi

oupss i< created a bug...

I have another bug with ReadOnly, I will check this weekend


Right way to get a string from JerryScript?

I am working on writing wrappers for the rlutil library, and right now I am a bit lost on the way to convert jerry_value_ts into char*s.
static jerry_value_t
rlutil_setConsoleTitle(
    const jerry_value_t func_value,
    const jerry_value_t this_value,
    const jerry_value_t *arg_p,
    const jerry_value_t arg_cnt
) {
    if(arg_cnt != 1) {
        // handle eerror
    }

    jerry_size_t len = jerry_get_string_size();
    char str[len + 1];
    jerry_string_to_char_buffer(arg_p[0], &str, len);

    setConsoleTitle(str);

    return jerry_create_undefined();
}

I haven't had a opportunity to test just yet - writing this in my break time :). But, is this the correct way of doing this, and is there possibly a better way?
Thanks!

@IngwiePhoenix looks good to me.
Note: str[] will be local variable, so it won't be initialzed to zero. I'd add str[len] = 0; to your code to ensure it will be zero terminated.
In general, jerry_string_to_char_buffer is used for CESU8 encoded strings and jerry_string_to_utf8_char_buffer is used for UTF8 encoded strings. You can validate the jerry_value_t with jerry_is_valid_utf8_string or jerry_is_valid_cesu8_string. Furthermore you can compare the return value of jerry_string_to_char_buffer to jerry_get_string_size. They must be equal if the call was successful and all characters were copied to the buffer.
http://jerryscript.net/api-reference/#jerry_string_to_utf8_char_buffer

Note 2: UTF8 and CESU8 strings can contain zeros as valid characters, so it won't be zero terminated as you expect in your code. (Except if you guarantee it yourself)

@IngwiePhoenix looks good to me.
Note: str[] will be local variable, so it won't be initialzed to zero. I'd add str[len] = 0; to your code to ensure it will be zero terminated.

Oh! Good point :) Totally forgot that one...

In general, jerry_string_to_char_buffer is used for CESU8 encoded strings and jerry_string_to_utf8_char_buffer is used for UTF8 encoded strings. You can validate the jerry_value_t with jerry_is_valid_utf8_string or jerry_is_valid_cesu8_string. Furthermore you can compare the return value of jerry_string_to_char_buffer to jerry_get_string_size. They must be equal if the call was successful and all characters were copied to the buffer.

Ah, that might not be important for a console title, but for larger strings for sure. Thank you for pointing this out, useful thing to assert() for in some cases!

Note 2: UTF8 and CESU8 strings can contain zeros as valid characters, so it won't be zero terminated as you expect in your code. (Except if you guarantee it yourself)

I am currently thinking about a fast and efficient way to check if that buffer contains zeros or not - but for right now, this is not a big concern that I have. Still, good to have that in mind. :)
Thank you very much, @LaszloLango !

One more note: this only works with strings. If you have non-string values (numbers, objects, etc.) you should use jerry_value_to_string first.


Fix build failing to compile on master

Closes #1179

There is a PR removing this dependency #1177 . I am not sure it should be added again :P

Probably correct, I was just trying to make it compile.


Is there any ETA for new beta or official updates for the plugin?

Great plugin. Thanks for the awesome job. Just wondering if there are plans to release new updates in the near future for the plugin. Thanks.

I am also looking for a fix to the default Reading mode. Whenever I open it, it's always in Editor mode. Is this that we can expect to be fixed in near future.

Just installed 2.0.5 through this procedure , and it works like a charm for my simple usecase. Many thanks !

This is going to sound silly but what is the procedure linked in this comment? I have BRAT installed, but I'm not sure what the next step is supposed to be.
These are the BRAT-related commands I see in the palette in case it has to do with these:


Proposal:  Add BDD with cucumber

If anyone is interested in BDD (behavior driven design), we can use Cucumber like below.  But only if people are interested, since it adds another tool to learn (athough it's fairly easy).
There would be Rspec unit and integration tests in spec/ and Cucumber acceptance/system tests in features/.
As an author
  So that I can create an interesting new mythological story
  I would like to describe a story and submit it to the ai

  Background:
    Given the following mythologies exist
      | name | description |
      | Roman | Ancient Roman  |

  Scenario: Creating a new story
    Given I am on the home page
    When I click the "Generate a Story" button
    Then I should see "New Story"
    And I should see a form with:
      | Field |
      | Title |
      | Descriptions |
    Etc...

I think if we don't add cucumber, there should be good system tests in minitest or rspec:
See https://guides.rubyonrails.org/testing.html#system-testing.
Maybe follow these guidelines: https://evilmartians.com/chronicles/system-of-a-test-setting-up-end-to-end-rails-testing.


Edit mode with fixedColumns option breaks table layout

Describe the bug
In a table with fixedColumns option, when editing a row, the save/cancel buttons disappear.
To Reproduce
Steps to reproduce the behavior:

Go to Editable demo: https://material-table-core.com/demos/edit/editable
Paste this code on the Live Demo editor:

function BasicEditPanelDemo() {
  const [data, setData] = useState(EDITABLE_DATA);
  const columns = [
    { field: 'id', title: 'Id', editable: 'never', width: 100 },
    { field: 'firstName', title: 'First Name', width: 200, },
    { field: 'lastName', title: 'Last Name', width: 200, },
    { field: 'lastName', title: 'Last Name', width: 200, },
    { field: 'lastName', title: 'Last Name', width: 200, },
    { field: 'lastName', title: 'Last Name', width: 200, },
  ];
  return (
    <MaterialTable
      data={data}
      columns={columns}
      icons={TABLE_ICONS}
      options={{
        fixedColumns: { left: 1, right: 0 },
      }}
      editable={{
        onRowAddCancelled: (rowData) => console.log("Row adding cancelled"),
        onRowUpdateCancelled: (rowData) => console.log("Row editing cancelled"),
        onRowAdd: (newData) => {
          return new Promise((resolve, reject) => {
            setTimeout(() => {
              newData.id = "uuid-" + Math.random() * 10000000;
              setData([...data, newData]);
              resolve();
            }, 1000);
          });
        },
        onRowUpdate: (newData, oldData) => {
          return new Promise((resolve, reject) => {
            setTimeout(() => {
              const dataUpdate = [...data];
              // In dataUpdate, find target
              const target = dataUpdate.find((el) => el.id === oldData.tableData.id);
              const index = dataUpdate.indexOf(target);
              dataUpdate[index] = newData;
              setData([...dataUpdate]);
              resolve();
            }, 1000);
          });
        },
        onRowDelete: (oldData) => {
          return new Promise((resolve, reject) => {
            setTimeout(() => {
              const dataDelete = [...data];
              const target = dataDelete.find((el) => el.id === oldData.tableData.id);
              const index = dataDelete.indexOf(target);
              dataDelete.splice(index, 1);
              setData([...dataDelete]);
              resolve();
            }, 1000);
          });
        },
      }}
    />
  );
}

Confirm that the ID column is fixed when scrolling horizontally
Click on the edit button to edit a row
Cannot save because the buttons are gone

Even pressing ESC to cancel the edit leaves the table broken.
Expected behavior
Actions column should stay fixed even during edit mode.

Interesting... noticed that if trying with fixedColumns: { left: 2, right: 0 }, everything seems to be fine

Maybe the default fallback values for left and right are not set correctly. Would you mind checking if you can resolve this in the code?

@Domino987 where can we set the left and right values for the auto generated Actions column? Not sure if I'm tracking.

Hi @Domino987, the default overflow values seem to be marked as hidden for the fixedColumns.left, due to which the icons disappear on Edit.
`

 {
                              if (e.key === 'Tab') {
                                e.preventDefault();
                              }
                            }}
                          >
                            {table}

`
Marking the overflowX to visible or clip could resolve the issue. However, the width of the Action Item would require some additional modification on the Utils side.
Let me know if I can raise a PR for you to verify it.

This seems like a possible fix. That's for investigating this. A PR would be most welcome

@Domino987 the fix with the overflowX does resolve this issue, but it seems the shadow highlights for the fixed columns seems to disappear.
Might be a rookie mistake, but the clip value (instead of hidden) preserves the shadow property. I am not sure if there would be any other impact other than this.

Would you mind trying it out and if that works, add a PR?


Python 3 + Graphite 1.1.0

Coverage increased (+0.4%) to 79.732% when pulling fda020f31183b5e842facda99a51785a80d5ab35 on iksaif:python3 into cc850380ca346e91cacc57c1264e8f0e25c13d7e on criteo:master.

Coverage increased (+0.4%) to 79.732% when pulling 454f8eb9ac7b4937de7464f1ad22c72daf00ff28 on iksaif:python3 into cc850380ca346e91cacc57c1264e8f0e25c13d7e on criteo:master.

Coverage increased (+0.4%) to 79.732% when pulling d7a5268b838cf6dfccbbac71c5f99033caf5debf on iksaif:python3 into cc850380ca346e91cacc57c1264e8f0e25c13d7e on criteo:master.

Coverage increased (+0.4%) to 79.732% when pulling 07fc01c9a997699f5b72bdbaac60538a5865e10f on iksaif:python3 into cc850380ca346e91cacc57c1264e8f0e25c13d7e on criteo:master.

Coverage increased (+0.4%) to 79.732% when pulling 76d010d083acc2ca5bb936adb57dd6b7211756cb on iksaif:python3 into cc850380ca346e91cacc57c1264e8f0e25c13d7e on criteo:master.

Coverage increased (+0.4%) to 79.732% when pulling 07b9fe343d325a273087576537a693fe348a153a on iksaif:python3 into cc850380ca346e91cacc57c1264e8f0e25c13d7e on criteo:master.

Coverage increased (+0.4%) to 79.777% when pulling 53825afbe2e2ec941e35069b6d573136bf805ccd on iksaif:python3 into cc850380ca346e91cacc57c1264e8f0e25c13d7e on criteo:master.

Coverage increased (+0.4%) to 79.732% when pulling eecea4820496676a504457ef17be2d713aa8e988 on iksaif:python3 into cc850380ca346e91cacc57c1264e8f0e25c13d7e on criteo:master.

Coverage increased (+0.4%) to 79.732% when pulling eecea4820496676a504457ef17be2d713aa8e988 on iksaif:python3 into cc850380ca346e91cacc57c1264e8f0e25c13d7e on criteo:master.

Coverage increased (+0.4%) to 79.768% when pulling b34b7c76fca6cedec38dcca60ae5109f3290894b on iksaif:python3 into 76fe6db945191b6ca78288d4dcda68803d4a1bd2 on criteo:master.

Coverage increased (+0.4%) to 79.768% when pulling ac2d00b3c28adc8f5160e7ed85ada0eb68dbe06d on iksaif:python3 into 76fe6db945191b6ca78288d4dcda68803d4a1bd2 on criteo:master.

Coverage increased (+0.4%) to 79.768% when pulling 4b727176813f45fd37e6f386317bdc3415ced47a on iksaif:python3 into 76fe6db945191b6ca78288d4dcda68803d4a1bd2 on criteo:master.

Better now


Add finding hotkeys

This PR adds an edit and save hotkey to the process of finding creation.
If you view a finding on the view_finding.html, you can press "e" to edit the finding. If you are in promote, edit, add from template or add a add new finding editor, you can press "ctrl+s" to save the finding. This behaviour helps in the work with findings or in the review.

@no-sec-marko That's a nice little feature to have! @devGregA ok to merge?


How does this help existing code?

I raised this at TC39 today; copying it out here.
I don't think we should be adding features to aid writing eval in any new code. I understand that isn't the goal: that the broader goal of this proposal is to allow more fine-grained control over eval so that people stuck using legacy codebases aren't forced to just use unsafe-eval. But since legacy codebases are, by definition, not using trusted types or whatever other new feature allowed producing evalable things, how does this help meet that goal?

Fyi, per @annevk's request, I combined the host callout and evalable proposals, and transferred this issue to the merged proposal.

@bakkot,

The value it returns is never exposed to user code, is it?

Correct.  The args list and its return value are both internal lists created by other spec abstractions or host callouts, not JS arrays.

I don't think we should be adding features to aid writing eval in any new code.

I tend to use the term "eval" loosely to mean code from string loaders including eval(x), Function(x), import('data:text/javascript,' + x), and even setTimeout(String(x), ms).
Are you objecting specifically to eval (indirect &| direct) or to all of the above?

I don't know of any feature that is straightforward to adopt and that might reduce the attack surface for pre-existing uses of eval that would not also aid writing eval in new code?
If not, it seems that this standard would prevent all features that might reduce the attack surface for pre-existing uses of eval.
So I have to question whether this is an appropriate standard to apply.

That said, I also would rather developers not use any of those flavours of "eval" in new code.
But if I had to choose between

aiding developers in using "eval" in new code in a way that enables blue team oversight
providing an alternative to turning off code loading guards when a carefully reviewed use of eval seems the most straightforward path to a new feature
I prefer the latter.

It took quite a while to come to this preference, because dynamic code loading seems like using dynamite to catch fish.
My change in view was based on several realizations:

eval currently prevents strict CSP adoption for many large apps
replacing a use of eval(myString) with eval(myTrustedScript) does not expand attack surface
if an app replaces every use of eval(myString) with eval(myTrustedScript) and whitelists every policy it still reduces attack surface by shutting off implicit Function: ({})['constructor']['constructor'](code).
applications do not migrate in one fell swoop.  It took > 1 year to migrate Gmail to TT for server-side code.  We started by just approving a lot of dodgy, unreviewed stuff, and then repeatedly polished the stone until we got to a better place.

But since legacy codebases are, by definition, not using trusted types or whatever other new feature allowed producing evalable things, how does this help meet that goal?

I think it's important to distinguish between 2 different kinds of legacy:

Legacy applications where the migrators have direct control over the source code.
Legacy third-party dependencies which are harder to adjust

Both new and legacy applications developed alongside TT may have legacy dependencies.
Legacy applications may use trusted types.  Just not for all trust decisions.
A legacy application is just one that was not developed alongside TT and so which is in the process of migrating.
There are a few use cases where I expect legacy dependencies would persist in libraries even in
Here are some common use cases:
Constant patterns
<meta http-equiv="Content-Security-Policy" content="trusted-types default">
<script>
// Application code defines a default policy
Trusted.createPolicy(
  'default',
  {
    createScript(x) {
      if (/^return this;?/.test(x)) {
        // Make sure there's a semicolon at the end so that
        // the result can be safely concatenated with other TrustedScripts.
        return 'return this;';
    },
  });
</script>
<script>
// Legacy library code uses `Function` as a strict mode escape to access the global scope
// appears in lodash, and other libraries that have large installed bases, code size constraints,
// and need to support old interpreters.
(new Function('return this')())
</script>

Formulaic metaprogramming
I'm mostly familiar with this in Node.js code.
Widely used libraries like depd use new Function to create function wrappers that have the same .length so that they work with reflective code like promisify.
Note that fairly recent versions of depd used eval instead of new Function.
Since this is formulaic, it's easy to recognize and handle using a default policy.
Code that hasn't been migrated yet
One common use case for large, legacy applications is ad-hoc reporting: letting the user specify arithmetic equations which are used to generate a column in an HTML table that shows data.
In "What about eval":

Mathjs is often called with untrusted inputs. If a developer wanted to let a user generate an ad-hoc report without having to download data into a spreadsheet, they might use Mathjs to parse user-supplied arithmetic expressions (docs) instead of trying to check that an input is safe to eval via RegExps. It is not without risk (advisory) though1.

Since this writing, Mathjs got rid of all uses of eval

Starting the migration process and being able to turn on some protections even if the attack surface is still large is a necessary first step.
There's a problem akin to penguins clustering at the water's edge reluctant to enter.
There's little incentive for libraries like depd or Mathjs to increase code size to not use eval until they have a significant number of clients that would be able to reduce their attack surface by not using eval.  Smaller libs like Mathjs (josdejong was unusually proactive) have no incentive as long as they can say "depd blocks almost all my clients anyway."  Large libs like lodash & depd likewise have little incentive as long as they believe there's a long tail of small libs preventing.
I see eval TT guards as a way to break that deadlock.

Anyway, apologies for the length, and thanks for agreeing to take this offline.

Thanks for the reply!

Are you objecting specifically to eval (indirect &| direct) or to all of the above?

All of the above.

Legacy applications where the migrators have direct control over the source code.

I would strongly prefer that these migrators be forced to get rid of eval (and equivalents) entirely in the code they control. I realize this means some people will leave unsafe-eval on instead of getting rid of it, but I think it also means some people will get rid of eval instead of using trusted types to prolong their usage of it. I think taking a hard line on this is the only way we'll end up in a world where people no longer ship code with eval.

Legacy third-party dependencies which are harder to adjust

I agree that it's a huge improvement to have a default policy which can restrict which strings are allowed to be passed through to eval, but it seems to me that such a policy is enforceable purely in terms of the proposed HostBeforeCompileValue, without needing evalable (or any other changes to the language). I'm still failing to understand how the addition of a language-level evalable helps these cases at all.
Can you give a concrete example of how the addition of evalable would be necessary for making legacy third-party dependencies work?

I would strongly prefer that these migrators be forced to get rid of eval (and equivalents) entirely in the code they control. I realize this means some people will leave unsafe-eval on instead of getting rid of it, but I think it also means some people will get rid of eval instead of using trusted types to prolong their usage of it.

I would also prefer this.  There's no reason it could not have happened over the last 3 years, so it seems to me there would have been pressure on widely used libraries like lodash, jquery, and others to get rid of eval (and equivalents), but I have not seen that pressure.
We would have seen pressure on webpack and other widely used tools to not produce output that uses eval, but if there is such pressure, I've not seen it.
@arturjanc Do you know of any stats on CSP policies migrating from 'unsafe-eval' to no 'unsafe-eval' on the web at large that might shed light on whether this is a viable goal?

it seems to me that such a policy is enforceable purely in terms of the proposed HostBeforeCompileValue, without needing evalable ... Can you give a concrete example ... ?

This is an excellent question.
The HostBeforeCompileValue changes are sufficient for new Function(...) and eval(myString) which includes the depd 1.x.x case.
That leaves uses of eval that are not translatable to Function and which take a TrustedScript value instead of relying on an implicit string->TrustedScript conversion via a default policy.

I can't point you at code, but it actually took us an inordinately long time to migrate a large Google application to turn off unsafe-eval because it predated JSON, and so used eval to unpack data received from the server.
It used* eval to unpack updates from the server that were in an almost-JSON format and then dispatched those to lots of other pieces of code that made many assumptions about the structure of those decoded values.

Had hard performance requirements on older browsers, so custom parsing was out.
Used array holes like [0,,2] extensively to minimize wire size.
Had many clients that expected undefined instead of null because of these holes.
Included NaN and Infinity.
and that was the quirks left over after we took care of quotes, \x escaping issues, and IIRC the use of f and t instead of false and true.

These inputs were large, and because of the performance requirements, trying to validate this using the default policy would not work, so we did something like (but not exactly because our client-side trusted-types relied on static analysis instead of policy objects)
const unpackResponse = (() => {
  const uncheckedConversionPolicy = new TrustedTypesPolicy(
      '...',
      // Approved for use in a limited scope.  See below.
      { createScript(s) { return s; } });

  return ({ status, responseText }) => {
    if (status === 200 && ...) {
      // backend.example.com is a known producer of TrustedScript responses
      // since it uses TrustedTypes for server side discipline.
      return (0, eval)(uncheckedConversionPolicy.createScript(responseText));
    }
    throw new Error(...);
  };
})();

You can imagine that this was benchmarked nine ways from Sunday so the actual code probably differs from this in important ways, but these are the kind of legacy-ish requirements that we hope to make it possible to disentangle.
Marking a value trusted manually has overhead that is independent of the size of the result, and can be made based on indicators apparent to a scoped policy like:

provenance (a client trusts responses from a server that is known to use trusted types discipline internally), or
safety by construction (e.g. form inputs are used to assemble arithmetic equations in JS that populate a tabular view)

which are not apparent to the unscoped default policy.
* there's some chance it still does

@arturjanc Do you know of any stats on CSP policies migrating from 'unsafe-eval' to no 'unsafe-eval' on the web at large that might shed light on whether this is a viable goal?

I don't have current data, other than the observation that ~82% of sites with CSP used 'unsafe-eval' a couple of years ago (Table 3, page 8 of the linked PDF). I doubt this has significantly changed since then.
Based on a more anecdotal data set, it seems like many popular sites are still actively relying on eval(), not just allowing it via CSP -- it's difficult to find major applications that have eliminated it completely.
My intuition matches @mikesamuel's here: it seems difficult to require developers to completely remove eval() from their apps. One horror story from a few years ago are Chrome's apps/extensions enforcing a default CSP which disallowed eval(), which resulted in libraries like AngularJS writing custom eval()-like intepreters in JS, completely undermining enforcement at the platform level and leading to new classes of vulnerabilities. It might be nice to avoid giving developers an incentive to do this again :)

which resulted in libraries like AngularJS writing custom eval()-like intepreters in JS, completely undermining enforcement at the platform level

Thanks.  Better not to have to amend GreenSpun's 10th to include JS:

Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

Thanks for the example. My understanding then is that evalable is targeted specifically at cases where all of the following hold:

the use of eval is under the author's control (i.e. not in a dependency)
the code being passed to eval is not sufficiently regular that it can be safely checked by a default policy
it is not practical to refactor this code to avoid eval
it is practical to refactor this code to create instances of a trusted type and pass them through to eval in a way which is obviously safe.

It is not intended to help with any other cases. Is that right?
If that's so, I would like to see data indicating that this case in particular is common enough to warrant a change to JS before we went ahead with it. I know eval is very common, and adding unsafe-eval is consequently also common, but I would expect almost all uses to fail one of the above four tests (especially the first) and hence not be relevant to the usefulness of evalable.

Sidebar: with the caveat that I have not fully read the trusted types proposal, why is it not possible to implement an equivalent of eval using just the default policy mechanism, along the lines of
<meta http-equiv="Content-Security-Policy" content="trusted-types default">
<script>
// Application code defines a default policy
{
  let trusted = new Set;
  trusted.has = trusted.has.bind(trusted);
  trusted.add = trusted.add.bind(trusted);
  trusted.delete = trusted.delete.bind(trusted);
  window.trusted = trusted;
  Trusted.createPolicy(
    'default',
    {
      createScript(x) {
        if (!trusted.has(x)) {
          throw new Error();
        }
        trusted.delete(x);
        return x;
      },
    });
}
</script>
<script>
{
  let trusted = window.trusted;
  delete window.trusted; // there are other ways of doing this, like import maps; it's just an example.
  const unpackResponse = (() => {
    return ({ status, responseText }) => {
      if (status === 200 && ...) {
        // backend.example.com is a known producer of TrustedScript responses
        // since it uses TrustedTypes for server side discipline.
        trusted.add(responseText);
        return (0, eval)(responseText);
      }
      throw new Error(...);
    };
  })();
}
</script>

Thanks for the example. My understanding then is that evalable is targeted specifically at cases where all of the following hold:

the use of eval is under the author's control (i.e. not in a dependency)
the code being passed to eval is not sufficiently regular that it can be safely checked by a default policy
it is not practical to refactor this code to avoid eval
it is practical to refactor this code to create instances of a trusted type and pass them through to eval in a way which is obviously safe.

It is not intended to help with any other cases. Is that right?

I don't think this is the case w.r.t. point 1. evalable is needed to make TrustedScript objects able to be passed to eval-like sinks with no backwards-compatiblity issues. These objects can be created by 1st party code, or 3rd party code, but in any case the 1st party (or whoever controls the response header) has control over their creation via policy name whitelists. We expect the majority of the code producing that to be 1st party, but there is an irreducible amount of a code that relies on eval out there in popular dependencies. That code might migrate to using TrustedScripts as well, and I believe this is an improvement over the current situation, which is impossible with current solutions.
Why is evalable not useful for 3rd party code? The default policy is an escape hatch that we can use if the code continues to use eval(string), but if that code (be it 3rd party) decides to create TrustedScript objects, why would that be discouraged more than for 1st party? After all, the 1st party gets more control over the code in that regard, not less (even taking into account existing capabilities of CSP), allowing it to lock down eval even more than what is practically possible today.

If that's so, I would like to see data indicating that this case in particular is common enough to warrant a change to JS before we went ahead with it. I know eval is very common, and adding unsafe-eval is consequently also common, but I would expect almost all uses to fail one of the above four tests (especially the first) and hence not be relevant to the usefulness of evalable.

One indication I can provide is we did a review of popular JS libraries a while ago - https://ai.google/research/pubs/pub46450. 10 out of 16 used eval() in a way that's essential to them, mostly for implementing expression language support for the templating system.

Sidebar: with the caveat that I have not fully read the trusted types proposal, why is it not possible to implement an equivalent of evalable using just the default policy mechanism, along the lines of
<meta http-equiv="Content-Security-Policy" content="trusted-types default">
<script>
// Application code defines a default policy
{
  let trusted = new Set;
  trusted.has = trusted.has.bind(trusted);
  trusted.add = trusted.add.bind(trusted);
  trusted.delete = trusted.delete.bind(trusted);
  window.trusted = trusted;
  Trusted.createPolicy(
    'default',
    {
      createScript(x) {
        if (!trusted.has(x)) {
          throw new Error();
        }
        trusted.delete(x);
        return x;
      },
    });
}
</script>
<script>
{
  let trusted = window.trusted;
  delete window.trusted; // there are other ways of doing this, like import maps; it's just an example.
  const unpackResponse = (() => {
    return ({ status, responseText }) => {
      if (status === 200 && ...) {
        // backend.example.com is a known producer of TrustedScript responses
        // since it uses TrustedTypes for server side discipline.
        trusted.add(responseText);
        return (0, eval)(responseText);
      }
      throw new Error(...);
    };
  })();
}
</script>

Default policy is an escape hatch, and we'd rather promote a design that uses regular, named policies, that allow you to decouple trusted value production from consumption. Using types to represent a "trusted" value allows us to write static analysis rules that guide developers and warn them on errors that would break at runtime (like e.g. eval(string) if no default policy exists, or it doesn't convert any value). Additionally, types allow us to group values that might be used in various similar context. For example, TrustedScript is not only used for eval, but for some DOM sinks (like HTMLScriptElement.src) as well.

Why is evalable not useful for 3rd party code?

I was following @mikesamuel's taxonomy above:

Legacy applications where the migrators have direct control over the source code.
Legacy third-party dependencies which are harder to adjust

evalable is useful for third party code only if that code has been updated to use trusted types and then updated in the first party application. It is not useful for existing third party code, over which an application author has no direct control.

We expect the majority of the code producing that to be 1st party, but there is an irreducible amount of a code that relies on eval out there in popular dependencies. That code might migrate to using TrustedScripts as well

Is there reason to expect these dependencies to migrate to TrustedScripts, and not to migrate off of eval? For example, have you talked to any such popular dependencies (ideally non-Google-controlled ones) about this proposal?

10 out of 16 used eval() in a way that's essential to them

Interesting. I read the paper, but don't see this specific claim in it; can you point me to where I should be looking?

Using types to represent a "trusted" value allows us to write static analysis rules that guide developers and warn them on errors that would break at runtime

Are you planning to build this static analysis into Chrome's devtools? If not, is there reason to expect adoption of such a static analysis outside of Google?

Would it at least be accurate to say that evalable is not useful for any existing code, but the hope is that convincing people to update their code to use trusted types will be easier than convincing them to get rid of eval?

Why is evalable not useful for 3rd party code?

I was following @mikesamuel's taxonomy above:

Legacy applications where the migrators have direct control over the source code.
Legacy third-party dependencies which are harder to adjust

evalable is useful for third party code only if that code has been updated to use trusted types and then updated in the first party application.

Correct (though in the web platform, the distinction between the 1st and 3rd party code is a bit artificial, as everything gets the same capability, and an application is very rarely written with code solely authored by a single entity).

It is not useful for existing third party code, over which an application author has no direct control.

... if that code uses eval(string). The 3rd party code changes not only as a result of direct control by the first party. There is an advantage to using eval(TrustedScript) over eval(string), and it's perfectly reasonable for 3rd party authors to change the code on their own.

We expect the majority of the code producing that to be 1st party, but there is an irreducible amount of a code that relies on eval out there in popular dependencies. That code might migrate to using TrustedScripts as well

Is there reason to expect these dependencies to migrate to TrustedScripts, and not to migrate off of eval? For example, have you talked to any such popular dependencies (ideally non-Google-controlled ones) about this proposal?

We did not do an outreach for eval in specific,  but a strong reason to believe this might be the case is that migrating to TrustedScripts is trivial (TT.createPolicy + aPolicy.createScript call), whereas migrating off-eval is definitely not, and sometimes it's even impossible.

10 out of 16 used eval() in a way that's essential to them

Interesting. I read the paper, but don't see this specific claim in it; can you point me to where I should be looking?

The last table in the paper shows libraries that have used eval functionality, which we abused to trigger script gadgets. This core functionality for most of them was parsing author-controlled expressions in their templating languages. Listing 7 shows how that code usually looks like. It is possible not to use such pattern, but it requires a major refactor and usually leads to using a pattern which, from the security perspective, is worse than eval that at least is visible in the code (see @arturjanc comment about AngularJS). What you might end up with is a Turing-complete VM that still allows for arbitrary code execution, when the string input is user controlled, but it "appears" to be safe as it doesn't use eval. In principle, there is a better way (e.g. some frameworks moved to precompile their templates such that the expression parser is not present at runtime), but that is not possible for all deployments (i.e. it ties you to a build system used by a given framework, and requires a separate build step, which some authors don't use).
For such cases, it appears to be a better choice to focus on not getting user-controlled code to eval, but allow that function to exist in those limited usecases.
eval is used outside of this context as well, e.g. we use it in our anti-abuse detection mechanisms. As anecdata, we spent a few quarters trying to make that codebase not use eval, but weren't able to in the end.

Using types to represent a "trusted" value allows us to write static analysis rules that guide developers and warn them on errors that would break at runtime

Are you planning to build this static analysis into Chrome's devtools? If not, is there reason to expect adoption of such a static analysis outside of Google?

Why devtools? It seems like eslint / tslint would be better here. I guess you could use it in a browser, but that dynamic analysis, and the functionality is already there. CSP violations (which eval of string is) are visible in the console, there's also an event dispatched, so there's various ways to debug this dynamically already. Static analysis makes more sense in IDE or precommit hooks, and it's already used a lot in modern JS development. But to answer your question, yes, we intend to also write open-source tooling around TT, including the static analysis rules.

Would it at least be accurate to say that evalable is not useful for any existing code, but the hope is that convincing people to update their code to use trusted types will be easier than convincing them to get rid of eval?

It's a fair summary. evalable is definitely not useful for existing code, as existing code cannot - so does not - use eval(nonString) at all, apart from fringe cases that rely on eval(obj) === obj.
We (the web security community, not Google in specific) already tried for years to migrate people off eval with CSP. It just didn't work too well, and cannot possibly for for all codebases, especially the ones that are not actively maintained. This time we're trying to at least make sure to be able to assert that no user controlled data is passed to eval if one really needs to use it - and not have new instances of eval pop up uncontrollably.

My understanding then is that evalable is targeted specifically at cases where all of the following hold:

the use of eval is under the author's control (i.e. not in a dependency)

No.  Evalable is also targeted at library code.

the code being passed to eval is not sufficiently regular that it can be safely checked by a default policy

Correct.

it is not practical to refactor this code to avoid eval

It may provide value where it is not practical right now.
Trusted types aims to be a good migration target for large applications; some migrations might be multi-year efforts.

it is practical to refactor this code to create instances of a trusted type and pass them through to eval in a way which is obviously safe.

Correct.

Would it at least be accurate to say that evalable is not useful for any existing code, but the hope is that convincing people to update their code to use trusted types will be easier than convincing them to get rid of eval?

In strict mode, assuming no stack introspection, and assuming you can enumerate the local symbols you want the dynamically loaded code to access, eval doesn't allow you to do anything that new Function doesn't.
I agree with this mostly, but there are probably some weird meta-programming cases where eval in non-strict mode is used to introduce var declarations, or to call into stack-introspecting code, or where code generation is doing weird things (webpack) and the various parts of the code generator don't share context about which local declarations are needed.
For example, webpack has apparently benchmarked various ways to provide source mapping with delayed loading, and concluded that there are efficient ways that involve eval.  I don't understand the constraints involved, but I imagine, it'd be much less controversial to convince them to add another flag that takes a policy name and causes the webpack output to create TrustedScripts to pass to eval.  Here we've got a code generator that creates a policy that is available only within a scope, and is only used with string literals derived from trusted source files.

Is there reason to expect these dependencies to migrate to TrustedScripts, and not to migrate off of eval?

That's a good question, but I just don't know.

@bakkot, What's your level of comfort with this now?

Here's a concrete use case for direct eval that cannot be ported to new Function and which would ideally not work with a string input.
// Sometimes we want node's require, not webpack's.
const nativeRequire = eval('require');

This is some node.js code, so not browser relevant, so I understand if you say that Trusted Types should not be concerned with this.
The notable features are:

This workaround requires direct eval since it is a workaround to a code rewriter, and refers to a formal parameter.
It takes a constant but that constant is not safe in all contexts, since require is a powerful function.
The argument for safety depends on how nativeRequire is subsequently used.

I came across this in the wild (a Twitter thread actually) which I can dig up if anyone is interested.

In that case, the package should use the "browser" field to specify a separate browser-only entry point (or false) - code that shouldn't be shared across node and browsers, shouldn't be shared :-)

Is there reason to expect these dependencies to migrate to TrustedScripts, and not to migrate off of eval?

It is practically impossible to migrate existing codebases completely off eval in the web platform at scale, and the data confirms this - e.g. Table 3 from CSP Is Dead, Long Live CSP shows that >81% of CSPs have to use unsafe-eval, there's also a more modern list here. We've given examples on how migrating off eval is impractical on this bug, but to reinforce the argument - e.g. Google Tag Manager library uses it as well, capping the websites using it to 'unsafe-eval' level of security.
Most of the eval usage does not cause Cross Site Scripting though, as externally-controlled data is not passed to these calls. Annotating these calls with evalable allows to lock down the configuration. A migration path is simple, and much, much easier than migrating off eval - and the authors naturally prefer that. We have given multiple examples of why this is preferable, I'm not sure reiterating that brings the discussion forward. I just want to point out that the feature is driven by author's feedback. We want to make our websites more secure and are willing to spend some time rewriting the code, but our analysis shows we can't move off eval. CCing @devd who mentioned that usecase as well.

@bakkot had expressed interest in alternative approaches that we considered.  I collected some of the history of the major design iterations we went through within Google.  It's got my byline since I talk about my experiences in app development, but it touches on attempts by a lot of different people.

Thanks for putting that together, @mikesamuel, and for talking this over with me offline; it is very helpful in understanding where you're coming from with this proposal.
So, to summarize this thread:

There is, empirically, a lot of use of unsafe-eval in the wild.
You believe many of those uses are essentially intrinsic, and hence that there is no reason to expect the majority of libraries and applications which are today relying on eval will ever migrate off of it. In particular, you don't think that a best practice of having a CSP which disallows eval will ever create enough pressure on current library or application maintainers to remove those uses, even for libraries and applications which are actively maintained by people with security in mind. So you would like to find other ways to make eval more safe, even at the expense of reducing pressure to remove eval entirely.
By contrast, you expect it will be possible to convince library authors to use trusted types, and in particular to do so in an auditable way - so that the policy is actually and observably safe, and does not just launder whatever is passed to it.
Once all of the libraries used by a given application have done so, your hope is that application authors will then replace any non-library uses of eval in their application with correct uses of trusted types, add all of the policies from their dependencies (and their own policy) to their CSP header, and remove unsafe-eval.

Obviously this would only happen on a fairly long timescale. So this relies heavily on a belief that the ecosystem will still be such that eval is in common use a decade from now even in actively maintained libraries and applications. (If I understand correctly, this proposal is not really intended to help applications which rely on libraries which are not actively maintained - even if those libraries have been carefully audited, this proposal provides no mechanism to allow their usages of eval.)
Is all of that accurate?

As a small quibble with your design history document, you say

Any definition of “privileged code” that doesn't survive web bundling is untenable.

but it seems to me that it is untenable only under the assumption that the common practices for loading JS on the web will remain essentially static even on the timescales which would be needed for this proposal to see wide adoption. I am not convinced that this will be the case; I had understood that it was the intent of browsers to obviate the need for bundling by use of HTTP/2 push or web packages or other means.

@bakkot
As discussed in person

You believe many of those uses are essentially intrinsic, and hence that there is no reason to expect the majority of libraries and applications which are today relying on eval will ever migrate off of it.

Agreed.  We are also interested in "will not migrate off in the short term."
Whitelisting most obvious, intentional uses of eval in existing code is an important stepping stone to lock things down since it blocks non-obvious uses of eval.

So you would like to find other ways to make eval more safe, even at the expense of reducing pressure to remove eval entirely.

In our experience, showing a feasible migration path puts pressure on removing eval.

Obviously this would only happen on a fairly long timescale. So this relies heavily on a belief that the ecosystem will still be such that eval is in common use a decade from now even in actively maintained libraries and applications.

It's a long road, but I think "decade" may be an overstatement.  Some will adopt faster than others.  Gmail took less than a year to get significant benefit from server-side trusted types, and about 2 years for the bulk of the migration to complete, even though it took several more years before it was eval free.

If I understand correctly, this proposal is not really intended to help applications which rely on libraries which are not actively maintained

An unmaintained library that delegates its security-sensitive operations to a maintained library should be fine.
In our experience, showing a feasible migration path for many clients makes it cost-effective to find new maintainers.

OK. I am satisfied that the tradeoff of "some people will use this who would instead have just avoided eval" vs "some people will use this who would instead have used eval with no guardrails" is, on the net, and in light of all of the above discussions, likely to work out to being an overall a reduction in the amount of danger users of the web are exposed to, relative to not doing this. I'm also convinced by our conversations and the history document you put together that an approach similar to this one is likely the best option.
Thanks for talking through this with me, and for more fully laying out the target audience of this proposal. I'll go ahead and close this issue.


Rename classes

Update README
Update version
Close #36

Codecov Report

Merging #37 (454e711) into main (91ca644) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main       #37   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           59        59
  Lines          887       887
=========================================
  Hits           887       887

Impacted Files
Coverage Δ

aioalfacrm/entities/__init__.py
100.00% <ø> (ø)

aioalfacrm/managers/__init__.py
100.00% <ø> (ø)

aioalfacrm/client.py
100.00% <100.00%> (ø)

aioalfacrm/core/__init__.py
100.00% <100.00%> (ø)

aioalfacrm/core/entity.py
100.00% <100.00%> (ø)

aioalfacrm/core/entity_manager.py
100.00% <100.00%> (ø)

aioalfacrm/core/paginator.py
100.00% <100.00%> (ø)

aioalfacrm/entities/branch.py
100.00% <100.00%> (ø)

aioalfacrm/entities/customer.py
100.00% <100.00%> (ø)

aioalfacrm/entities/group.py
100.00% <100.00%> (ø)

... and 35 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 91ca644...454e711. Read the comment docs.


bug: Unable to update plugin due to helptag conflict

Did you check docs and existing issues?

[X] I have read all the lazy.nvim docs
[X] I have searched the existing issues of lazy.nvim
[X] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)
NVIM v0.10.0-dev-468292d
Operating system/version
Windows 11 Pro 23H2 / Ubuntu 22.04.3
Describe the bug
vim-jp/vimdoc-ja may fail to update.
This is a plugin that contains vim help files translated into Japanese.
It is believed that this issue is caused by unconditionally updating the plugin's distribution file.
Ref: https://github.com/vim-jp/vimdoc-ja/issues/279
Steps To Reproduce

Run nvim -u repro.lua
Run :Lazy update
Failed plugin update

Expected Behavior
Successful plugin update
no error occurs
Repro
-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  "folke/tokyonight.nvim",
  -- add any other plugins here
  "vim-jp/vimdoc-ja",
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here
vim.opt.helplang = { "ja", "en" }

https://github.com/vim-jp/vimdoc-ja/issues/279#issuecomment-1793395102


Add missing field suggestions

Pretty cool!
I realize it is probably easier to write this stuff in elisp, but it would be nice if such logic was instead written in Haskell so that this can be shared with editors other than emacs.


Crashing back to desktop on steam version 1.3.0

The recent update to MGS2 and 3 crashes with using this, shows its playing and maybe even shows the loading screen and then just force quits. I'm presuming it's due to the launcher edits they've made to the launchers.
I'm sure you're aware of the recent update to the collection and you're already working on an update but I thought i'd just post a thing of it. feel free to close it if not needed #

No crashing here with the latest update and MGSHDFix v1.0 (both skipping launcher and going through the launcher.)
May want to verify your game's files through steam, and post your logfile.

sure ill give that a go.
incase it doesnt work where are the log files stored?

I've also quickly tested out MGS3 yesterday, and MGS2 with today's patch and they seem to still work fine.

sure ill give that a go. incase it doesnt work where are the log files stored?

The log should be MGSHDFix.log and it will be in the game folder next to the main executable.

thanks for the replies, im gonna try this now. im thinking the update has overwritten the ASI loader so ill try it again and if dont have any luck ill post logs :)

Thanks all for your help sorry for wasting your time with this. huge error on my part


Doubts on design choices

I'm a little puzzled with some design choices:

Why Button has a .on_press but TextInput uses a callback in the constructor?
Why a callback in  TextInput and a message on Button? why not a stateful closure with no argument?
Text accepts a String but TextInput only accepts a &str. Why is that? This is restrictive when you try to create a NumberInput but you cannot use 6.to_string() in your TextInput.

Because I feel buttons should be able to be disabled, and text inputs shouldn't.
Why would you use a sateful closure with no argument? What's the point?
No reason. It started this way and I forgot to change it to stay consistent with the other widgets.

These are hardly design choices, just the result of an experimental API. We are still figuring things out, nothing is set on stone.

I don't understand what you mean with disable in this context.
The 'strong' argument is consistency.
I'm still a little shy for PRs, I'm new to rust. I've read the book but now that I'm do some code I'm having a lot of surprises...

I don't understand what you mean with disable in this context.

The idea is that if you do not use Button::on_press, then that button will appear as disabled. I simply wanted to play with this idea and see how it works in practice. We may change TextInput (and other widgets) if it works well.

The 'strong' argument is consistency.

Consistency can be subjective. I think it is consistent to use a closure only if we need one. I believe APIs should be hand crafted with each use case in mind.

I'm still a little shy for PRs, I'm new to rust.

No worries! Feel free to ask any questions. And welcome to Rust!

The idea is that if you do not use Button::on_press, then that button will appear as disabled. I simply wanted to play with this idea and see how it works in practice. We may change TextInput (and other widgets) if it works well.

I like your idea, I think for other widgets it would be easier to understand if the had the same behavior. At some point you may have widgets with more then one listener. I like more the .on_press

Consistency can be subjective. I think it is consistent to use a closure only if we need one. I believe APIs should be hand crafted with each use case in mind.

I can accept that but, for my current experience, it makes it harder to learn as you look for one pattern but it may be different for other widgets.

No worries! Feel free to ask any questions. And welcome to Rust!
:-)

The idea is that if you do not use Button::on_press, then that button will appear as disabled.

While I like this feature, I only found out that this is how you you're meant to do it by finding this thread. It might have been in one of the demos but I didn't remember/encounter it. Searching in the docs for "disabled" only comes up with the "disabled" stylesheet for button, which I was looking into until I found this thread.
I understand that iced is still under development, just thought it's worth mentioning that it should be specifically documented if you choose to stick with this implementation, as it may not be what people expect coming from other frameworks (even though this way makes perfect sense).
I could do a pull request to modify the 'tour' example - when you get to the "Radio button" stage, it currently entirely hides the "next" button rather than disabling it - fixing this would showcase the feature. That might have been why I thought the "disabled" feature wasn't implemented yet. But I would also need to recolor the "back" button, because the "back" button in the tour example is currently colored grey, which may be interpreted as being "disabled", when it's actually clickable.

I don't know how is the current implementation but could .on_press be a Trait?
This way one could implement the Clickable for other widgets and get a consistent interface.


WIP: Refactor ciao-cli

Here be dragons! Enter at your peril! Beware of the leopard.
This PR contains my current work to split ciao-cli into command code an client code. All the client code is currently accruing in client.go but will be moved into its own package and split up afterwards (this is to simplify the refactoring.)

Changes Unknown when pulling 3dac5c0a28d3930e9aa50575a4b29b7ed4e9e7ab on rbradford:refactor-ciao-cli into ** on ciao-project:master**.

Changes Unknown when pulling afa72ac60378023ae8b0248008801fdc9b773e76 on rbradford:refactor-ciao-cli into ** on ciao-project:master**.

Changes Unknown when pulling a4e03e561b36a5445098ede7f076cab6e1203f16 on rbradford:refactor-ciao-cli into ** on ciao-project:master**.

Changes Unknown when pulling 2784ff6a54ca3eaceb604ee9247642e1f6354528 on rbradford:refactor-ciao-cli into ** on ciao-project:master**.

Coverage remained the same at 65.739% when pulling e6fb2047f1e8dcbd5190e8b2e80575d0cc79cd4b on rbradford:refactor-ciao-cli into f6b599eae4709c83bbe7dae65a26e5084177b8d9 on ciao-project:master.

Coverage decreased (-0.02%) to 65.716% when pulling e6fb2047f1e8dcbd5190e8b2e80575d0cc79cd4b on rbradford:refactor-ciao-cli into f6b599eae4709c83bbe7dae65a26e5084177b8d9 on ciao-project:master.

Coverage decreased (-0.02%) to 65.716% when pulling e6fb2047f1e8dcbd5190e8b2e80575d0cc79cd4b on rbradford:refactor-ciao-cli into f6b599eae4709c83bbe7dae65a26e5084177b8d9 on ciao-project:master.

Coverage increased (+0.005%) to 65.743% when pulling b23f6a52b9a3c09df92fdcf4eadf928e8cb62d51 on rbradford:refactor-ciao-cli into f6b599eae4709c83bbe7dae65a26e5084177b8d9 on ciao-project:master.

Coverage increased (+0.005%) to 65.743% when pulling 13ce06c7a6f0582c2be817f37c0ef2660ee1a9c0 on rbradford:refactor-ciao-cli into f6b599eae4709c83bbe7dae65a26e5084177b8d9 on ciao-project:master.

Coverage increased (+0.005%) to 65.743% when pulling 0c2f7b480d2392e90fef6348cfbcc002c3fc3d9f on rbradford:refactor-ciao-cli into f6b599eae4709c83bbe7dae65a26e5084177b8d9 on ciao-project:master.

Coverage remained the same at 65.666% when pulling bbed5b9584ad5a7aa700d91ce10a31f6d330c052 on rbradford:refactor-ciao-cli into b2a8a2ecea1318ae28a0861191ec385532491b5a on ciao-project:master.


Error prone toUint8Array method

I've faced that toUint8Array method treats input as ASCII string: https://github.com/MasterKale/SimpleWebAuthn/blob/bc9ad0f68fc49c4ac23cd22428248faa26d3f9b6/packages/browser/src/helpers/toUint8Array.ts#L6
It is impossible to change transformation of challenge on the client.

Attestation https://github.com/MasterKale/SimpleWebAuthn/blob/bc9ad0f68fc49c4ac23cd22428248faa26d3f9b6/packages/browser/src/methods/startAttestation.ts#L27
Assertion https://github.com/MasterKale/SimpleWebAuthn/blob/bc9ad0f68fc49c4ac23cd22428248faa26d3f9b6/packages/browser/src/methods/startAssertion.ts#L27

Whats wrong?
First: Challenge verification will fail if challenge string contains non ASCII character. For example: abcж yep, ж occupy 2 bytes.
const value = 'abcж';

const array = Uint8Array.from(value, c => c.charCodeAt(0));
const string = String.fromCharCode.apply(null, array);

/// 'abcж' !== 'abc6'
value !== string

Second: user may want to transfer challenge from server in different format:

ASCII string - current assumption
HEX string - I prefer this format
OCTET string
base64 or base64url strings
and so on

So it would be better to allow user configure challenge encoding or move conversion and appropriate helper(s) to userland instead hard coded into the lib.

Thank you for reporting this, I think it's a fair point that the library should support UTF-8 strings. I'll look to fix that in the next release.
Regarding other potential challenge formats: the primary reason ASCII is assumed is because challenges need to be transmittable as application/json content. While I'm willing to concede the point that UTF-8 encoding can be considered de facto and so should be supported, I hesitate to commit to introducing support for arbitrary encoding/decoding of challenges. When a simple ASCII guid is sufficient as a challenge, where's the value in the library supporting myriad other encodings? The name of the library is SimpleWebAuthn, after all 😄

UTF-8 values in challenges should now be supported in the just-released @simplewebauthn/browser v0.7.3.

Hi, thank you.
For now it is impossible to use crypto.randomBytes(64).toString('hex') as a challenge because it doesn't have any sense to encode random bites as a UTF-8 string to transfer to client.
Also it is not mandatory to transfer data as application/json so it should be more appropriate to encode data as base64url (url safe) but not as a UTF-8 string.
I hope it should be possible to opt out of mandatory conversion of challenge as UTF-8 string to use own convention even in Simple library.

@MasterKale  One more argument against sending challenge as a UTF-8 string is that challenge came back from the client as a base64url string: https://github.com/MasterKale/SimpleWebAuthn/blob/e9ef3215693225203920e39707cc6abeca25ae44/packages/server/src/assertion/verifyAssertionResponse.ts#L79
So for consistency and to keep the library simple it would be better to send challenge from server to client (and decode as Uint8Array) as base64url string.

One of the bigger pain points of WebAuthn is that you have to pass in Buffers for things like challenge and user.id. The challenge is in transferring those server-generated values to the front end. As a long-time front end dev, I'm well aware that JSON is the de-facto method of getting those values from the back end to the front end. JSON doesn't support transferring arbitrary byte sequences unless you encode them to some kind of string, of which ascii and utf-8 encoding are the most common.

For now it is impossible to use crypto.randomBytes(64).toString('hex') as a challenge because it doesn't have any sense to encode random bites as a UTF-8 string to transfer to client.

You absolutely can use crypto.randomBytes(64).toString('hex') as a value for challenge when generating options for and verifying attestations because the call to .toString('hex') returns an ASCII-encoded string of characters.

So for consistency and to keep the library simple it would be better to send challenge from server to client (and decode as Uint8Array) as base64url string.

During attestation and assertion the authenticator takes the arbitrary-challenge-string-convereted-to-Buffer and base64url encodes it, which is why we encode the challenge to base64url within verifyAssertion(). There's no real benefit to double-encoding such values at any point in this chain...

And to clarify a "base64/base64url-encoded" string is a valid ascii-encoded string.

Yep, base64/base64url-encoded is a valid ascii string but it uses subset of 0-255 ascii symbols mapped to Uint8Array.
Encoding hex string as a ascii string (as you suggested) uses only 0-15 numbers for each of Uint8Array slot (numbers 0-255).
Yep, it works but it is requires dirty hack on server side to convert true buffer of random bytes from crypto.randomBytes to hex decoded as ascii...

What kind of "dirty hack" on the back end are you referring to? I used this when calling generateAttestationOptions() in the example project and it worked without issue:
const challenge = crypto.randomBytes(64).toString('hex');

Ok, let's go step by step:

WebAuthn requires Buffer (ArrayBuffer) to be passed.
It is common to pass Uint8Array (Implementation of ArrayBuffer).
Each element of Uint8Array is integer value in range 0-255.
When you convert any string to Uint8Array when each character is mapped to Uint8 (value between 0-255).

The issue: when you convert hex string to Uint8Array when you use only integers from from 48 (0) to 57 (9) 97 (a) to 102 (f).
The ascii and utf-8 strings have the same issue but not as clearly as hex because they have large cardinality. Usually you should not use symbols from 0 to 31 https://en.wikipedia.org/wiki/ASCII

Okay, so this is an argument against encoding bytes to hex since its representation in ascii doesn't use the full 0-255 range of characters? I guess I see how that could limit entropy when used as a challenge generation scheme, but not how it negatively affects SimpleWebAuthn's functionality as challenge generation happens outside of the library. SimpleWebAuthn expects a string simply because it can't prepare a JSON-compatible payload with values that are raw bytes.
According to the WebAuthn spec, the goal of the challenge is to prevent replay attacks by containing a lot of entropy:

In order to prevent replay attacks, the challenges MUST contain enough entropy to make guessing them infeasible. Challenges SHOULD therefore be at least 16 bytes long.

It sounds to me like it's up to the implementer to decide a challenge structure that's suitable for their use case. If it's decided that hex is unsuitable for generating enough entropy when represented as an ascii-encoded string then there are alternative encodings that can be used when generating challenges. In that case I'd end up interpreting your request as one to update the docs to indicate preferred ways to generate string values for the challenge parameter of generateAttestationOptions().

I guess what I'm really trying to get to is, what kind of improvement to SimpleWebAuthn are you requesting?

challenge generation happens outside of the library

Yep, but the user have to convert it to utf-8 string to be compatible with @simplewebauthn/browser library. Not every sequence of bytes could be converted to valid utf-8 string.
let's come from the other end. @simplewebauthn/browser library and underlaying navigator.credentials returns challenge as a base64url string. Why the library invents new format of ascii/binary string? Why not just pass to the library challenge as the same base64url string string to keep input and output similar and simple?
Any sequence of bytes may be encoded and transferred in JSON as base64url string even ascii and utf-8 strings and raw buffer.
So the simple option:

Input: base64url
Output: base64url

Strange option:

Input: utf8 string which will be encoded to buffer of bytes as char codes.
Output: base64url

Any sequence of bytes may be encoded and transferred in JSON as base64url string even ascii and utf-8 strings and raw buffer.
So the simple option:
- Input: base64url
- Output: base64url

This is currently supported, though...
const challenge = base64url.encode(crypto.randomBytes(64));
inMemoryUserDeviceDB[loggedInUserId].currentChallenge = challenge;

res.send(generateAttestationOptions({ ..., challenge });

SimpleWebAuthn enables devs to pick their poison with respect to converting an arbitrary Buffer to a string representation, base64url included.
This discussion has got me wondering if SimpleWebAuthn shouldn't internalize challenge generation too. generateAttestationOptions() could return options and the base64url string it used for challenge so that this can be solved in an opinionated manner that avoids too much bikeshedding...

This is currently supported, though...

Nope, It's look like it is supported. The issue is the same: to convert to UInt8Array with 0-255 values used alphabet with 64 different values. Because toUint8Array(requestOptionsJSON.challenge) is hard coded and user could not opt out using it.
Some code:
// bytes is Buffer which is Uint8Array https://nodejs.org/api/buffer.html#buffer_buffer
const bytes = crypto.randomBytes(64);

// string to pass to client library @simplewebauthn/browser
const stringForClient = base64url.encode(bytes);

// from helpers of client library https://github.com/MasterKale/SimpleWebAuthn/blob/master/packages/browser/src/helpers/toUint8Array.ts
const uint8array = toUint8Array(stringForClient);

// buffer generated on server not equal buffer passed to navigator.credentials
uint8array !== bytes

Do you understand me?

Okay, I see what's going on now. toUint8Array() doesn't convert stringForClient back to bytes, it converts the base64url-encoded representation of bytes to a Uint8Array, and so of course uint8array !== bytes.
While I consider this further I'm wondering if you can answer this: is there a sufficient security argument to be made for supporting arbitrary byte sequences as challenges instead of only supporting strings? Isn't a 64-character string containing random characters sufficient entropy for the challenge?

Okay, I see what's going on now. toUint8Array() doesn't convert stringForClient back to bytes, it converts the base64url-encoded representation of bytes to a Uint8Array, and so of course uint8array !== bytes.

Awesome! We made a progress!

is there a sufficient security argument to be made for supporting arbitrary byte sequences as challenges instead of only supporting strings? Isn't a 64-character string containing random characters sufficient entropy for the challenge?

What you think in term of security? "640K ought to be enough for anybody."

I think it should be possible to keep simplicity of library and solve the issue by the following:

Use base64url.encode in the server package to convert challenge. It accepts true Buffer and/or String as you like.
Replace toUint8Array by base64URLStringToBuffer to convert challenge to Uint8Array.

It allows to use any source for the challenge: crypto.randomBytes, any strings or even some special random source.

Awesome! We made a progress!

Thank you for your patience, it's a subtle flaw in the system and I was having a hard time seeing it.

I think it should be possible to keep simplicity of library and solve the issue by the following:

You're absolutely right, everything needed to encode and decode base64url already exist in both the front end and the back end. In fact I should be able to get rid of toUint8Array() completely after updating Browser accordingly. I'll go ahead and make these changes.
I'm also going to update generateAttestationOptions() and generateAssertionOptions() to generate challenges internally. I thought it'd be okay to leave it to the implementer to construct sufficiently-complex challenges, but after you're talking this through with me I realized the library should be in charge of generating these values because of all the gotcha's associated with it.

Yep build-in challenge generator would simplify usual use cases.
But, please leave the option to pass user defined Buffer/String challenge to generateAttestationOptions and generateAssertionOptions.
Motivation:

Some users may want use short challenge 16 bytes long to reduce communication package size.
In opposite to increase security it may be necessary to use challenge 64 bytes or even more.
Challenge storage question: fixed or dynamic length?

It makes no sense to provide all the options in the library, but the ability to pass custom challenge as Buffer/String instead of default would be awesome.

My plan is to update Server to make the challenge parameter in generateAttestationOptions() and generateAssertionOptions() an optional string | Buffer. If no value for challenge is provided, the library will generate one. If a value for challenge is provided, it'll be used instead.
The return values from these methods will now include the raw challenge, whether it was passed in or generated by the library. This will make it possible to pass directly into Server's verify...response() methods.
This'll be a breaking change, but it'll be worth it because it'll simplify and secure the use of the library even more :v:

Some thoughts:

If the library uses user provided challenge then the raw output is not necessary because user already has raw data for challenge to pass it to verify methods.
If the library generates default challenge then user may store base64url options.challenge but it requires verify methods to supports expectedChallenge as string | Buffer | base64url.

🤔

Another opinion: challenge for the server library is too storage related (*sql, mongo, redis etc) so it may be declared as out of scope of simple library.
Good readme how to generate challenge (crypto.randomBytes(64)) should be enough for the user.

If the library uses user provided challenge then the raw output is not necessary because user already has raw data for challenge to pass it to verify methods.

It'll get returned anyway for sake of a consistent return value. In those situations the implementer can simply ignore it 😄

If the library generates default challenge then user may store base64url options.challenge but it requires verify methods to supports expectedChallenge as string | Buffer | base64url.

The way I see it expectedChallenge can share the same type as the newly-optional challenge, string | Buffer. It'll still be base64url-encoded within verifyAttestationResponse()/etc... since the challenge from the authenticator will be coming in base64url-encoded. Besides, it'd be unpleasant to try and discern whether a string value is already base64url-encoded since typeof string === typeof base64urlString

typeof string === typeof base64urlString yep, it is to error prone...
See my previous comment https://github.com/MasterKale/SimpleWebAuthn/issues/39#issuecomment-665969097

Another opinion: challenge for the server library is too storage related (*sql, mongo, redis etc) so it may be declared as out of scope of simple library.

A single, simple, sane method of generating challenges is available to the library thanks to Node's crypto module, so I'm inclined to add it in.
Maybe instead of returning a raw Buffer by default I always return the base64url-encoded challenge, even when a custom challenge is provided. This way it always returns a value that's relatively easier to store across various storage solutions. That'd then mean updating the verify...() methods to no longer encode challenges internally, too... 🤔

Base64url is not fixed length encoding so it is impossible to use CHAR(64) to store it.
I'd prefer to have helper method to generate challenge outside generate* methods

CHAR(128) would be more than enough to store the 86 bytes in a base64url-encoded 64-byte Buffer, just use that, storage is cheap 😛

@mahnunchik #42 is the PR containing my tentative solution to this issue. Fortunately it's not as breaking a change as I described earlier, and more importantly it manages a variety of values for challenge including ascii strings, utf-8 strings, and crypto.randomBytes(64).
And for good measure I hand-checked the values being passed to authenticators by startAttestation()/startAssertion() to confirm that they were the actual strings/buffers I was passing in as challenge to generateAttesationOptions() and generateAssertionOptions() respectively.

PR #42 has been merged in with a fix for this issue. It is available in the newly released v0.8.0.


Tracking issue for the exhaustive documentation of the jsonrpc-client

This is a tracking issue in resolution of https://github.com/near/near-jsonrpc-client-rs/issues/37 as an attempt to exhaustively document the client. (https://github.com/near/bounties/issues/77)
A series of PRs documenting each of the artefacts below will be provided to complete this.
Meta

[x] https://github.com/near/near-jsonrpc-client-rs/pull/88
[x] https://github.com/near/near-jsonrpc-client-rs/pull/91
[x] Ensure all methods on JsonRpcClient + JsonRpcClientConnector are documented.
[x] https://github.com/near/near-jsonrpc-client-rs/pull/85
[x] https://github.com/near/near-jsonrpc-client-rs/pull/84
[ ] https://github.com/near/near-jsonrpc-client-rs/pull/92

RPC Methods

[x] https://github.com/near/near-jsonrpc-client-rs/pull/53
[x] https://github.com/near/near-jsonrpc-client-rs/pull/60
[x] https://github.com/near/near-jsonrpc-client-rs/pull/62
[x] https://github.com/near/near-jsonrpc-client-rs/pull/61
[x] https://github.com/near/near-jsonrpc-client-rs/pull/59
[x] https://github.com/near/near-jsonrpc-client-rs/pull/58
[x] https://github.com/near/near-jsonrpc-client-rs/pull/68
[x] https://github.com/near/near-jsonrpc-client-rs/pull/70
[x] https://github.com/near/near-jsonrpc-client-rs/pull/76
[x] https://github.com/near/near-jsonrpc-client-rs/pull/77
[x] https://github.com/near/near-jsonrpc-client-rs/pull/78
[x] https://github.com/near/near-jsonrpc-client-rs/pull/79
[x] https://github.com/near/near-jsonrpc-client-rs/pull/80

Experimental methods:

[x] https://github.com/near/near-jsonrpc-client-rs/pull/66
[x] https://github.com/near/near-jsonrpc-client-rs/pull/64
[x] https://github.com/near/near-jsonrpc-client-rs/pull/65
[x] https://github.com/near/near-jsonrpc-client-rs/pull/67
[x] https://github.com/near/near-jsonrpc-client-rs/pull/63
[x] https://github.com/near/near-jsonrpc-client-rs/pull/69
[x] https://github.com/near/near-jsonrpc-client-rs/pull/71
[x] https://github.com/near/near-jsonrpc-client-rs/pull/72

Sandbox methods:

[x] https://github.com/near/near-jsonrpc-client-rs/pull/75
[x] https://github.com/near/near-jsonrpc-client-rs/pull/81

Others

[x] https://github.com/near/near-jsonrpc-client-rs/pull/86
[x] https://github.com/near/near-jsonrpc-client-rs/pull/87
[x] https://github.com/near/near-jsonrpc-client-rs/pull/89

This effort is now complete.
@frol, thanks for taking the time to parse through it all.
And thanks, @iTranscend, for preparing these PRs. Sorry, it took a while 😅


Fix BE crash

_page_builder is not init , dereference a nullptr will crash.
What type of PR is this：

[x] bug
[ ] feature
[ ] enhancement
[ ] others

Which issues of this PR fixes ：

Fixes #4166
Problem Summary(Required) ：

Init _page_builder before dereferenceing it

you can execute following script to format you cpp code
cd build-support/
sh clang-format.sh

after do that and commit your formatted code to pass the starrocks_clang-format test.

I need some investigation to find the root cause of this problem, It seems that we forgot to call the set_encoding() before calling the append() method in some cases.

OK

Seems duplicated with #463


[✨] Qwik-city Link preventdefault:click

Is your feature request related to a problem?
Hello,
The preventdefault:click on <Link href="/qwik">  is ignored.
Describe the solution you'd like
Take into account preventdefault:click when using <Link /> component and do not trigger navigation when its present.
https://github.com/BuilderIO/qwik/blob/275e1c7723a0cf95d8e910514a8047a217bb137f/packages/qwik-city/runtime/src/link-component.tsx#L25
Describe alternatives you've considered
None
Additional context
Thank you

What's the use case for this?

Structure of the app:

routes :

[...workspace]

index.tsx <-- acts as dashboard
item

[id]

index.tsx <-- opens a modal with details

On top of all features its provides I need it for 2 uses cases

prevent scroll to top on click:

Imagine a page with a lot of items (with scroll)

Scroll a little bit
Click on one item
trigger the navigation (URL updated)
show a modal with details of that item
also scroll to top <- I want to prevent that.

replace state :

Sometimes I need to be able to replaceState (history API)

What's the use case for this?

A like button on a card which is wrapped by  tags - clicks to the Like button propagate through to the

is it still valid?


FBLPromises.xcframework missing mac_catalyst support

I am working to upgrade our firebase dependencies for their PrivacyManfiest.
After upgrading Firebase to version 10.22.0, Carthage is now failing to build all the frameworks due to the following error:
Failed to read file or folder at ../Carthage/Build/FBLPromises.xcframework/ios-arm64_x86_64-maccatalyst/FBLPromises.framework/FBLPromises
It looks like at one point there was a mac catalyst specific framework.

Hi @trevor-holliday-instacart, did you get the FBLPromises.xcframework from the Firebase carthage distribution? If so, could you please open this issue in the firebase-ios-sdk repo (template)?


[Dev] authentication errors handling

Codecov Report

Merging #49 into master will increase coverage by 0.05%.
The diff coverage is 62.22%.

@@             Coverage Diff              @@
##             master      #49      +/-   ##
============================================
+ Coverage     51.74%   51.79%   +0.05%
- Complexity      506      511       +5
============================================
  Files            96       98       +2
  Lines          2317     2334      +17
  Branches        136      139       +3
============================================
+ Hits           1199     1209      +10
- Misses         1037     1041       +4
- Partials         81       84       +3

Impacted Files
Coverage Δ
Complexity Δ

...m/axibase/tsd/client/AtsdServerMessageFactory.java
60% <60%> (ø)
4 <4> (?)

.../main/java/com/axibase/tsd/client/DataService.java
72.52% <60%> (-0.3%)
26 <1> (ø)

...c/main/java/com/axibase/tsd/client/HttpClient.java
79.31% <61.9%> (-0.18%)
33 <3> (-1)

...axibase/tsd/client/AtsdServerExceptionFactory.java
66.66% <66.66%> (ø)
2 <2> (?)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f4c95c8...88ba659. Read the comment docs.


Spanish translation 1.18

After all this suffering for really strange bugs... Finalle come out! Full spanish translation to 1.18 version (lang file and dictionary of spirits full).

Fantastic work, thanks a lot!


Allow index.js to be set to any file

Is your feature request related to a problem? Please describe.
I'm using TypeScript and wish for my index.js file to be index.ts, but I cannot currently do that.
Describe the solution you'd like
https://github.com/nozzle/react-static/blob/master/docs/config.md#paths allows us to change src to anything we want, but it still requires us to have index.js in there.
An additional option could be added called entryFileName that defaults to index.js, allowing it to be overridden
Describe alternatives you've considered
An alternative to yet another option would be to look for src/index.*$, rather than src/index.js, allowing at least the file extension to be flexible.

This is already possible by adding this in your static.config.js:
export default {
  entry: 'index.ts',
}

I'm not sure why this is not documented, however the TypeScript template also uses this config option as can be seen here:
https://github.com/nozzle/react-static/blob/045a0e119974f46f68c633ff65116f9d74807caf/packages/react-static/templates/typescript/static.config.js#L8

Oh, well then I'll create a small PR to update the documentation :-)
I didn't use the any template so I didn't see this.
Thanks so much!


Unable to equip gems

Describe the bug
Since yesterday I'm unable to equip gems on items. In some cases you are able but the gem page shows up at the bottom of the item selection page, which is probably some UI rework but it's pretty bad. If I want to select gems for more items and click the gem tab the application doesn't display any gem menu.
To Reproduce
Steps to reproduce the behavior:

Go to rogue simulator
Click on an item in the character screen
Click on the gem tab
The gem window either concats to the item selection window or does not show up at all.

Expected behavior
The gem selection window to replace the item selection window.
Sim Links and Screenshots
Note the gem menu button is active (selected)
Desktop (please complete the following information):

OS: Mac OS Ventura 13.0.1
Browser chrome
Version: 109.0.5414.119 (Official Build) (x86_64)

can confirm. switching enchants etc. works fine for 1 item after refresh but after u try to mess with other items, it breaks.


[bug]: install on debian not working

Describe the bug
make test fails
To Reproduce (Required)
Steps to reproduce the behavior:
I tried to install it on debian 11.4.  I know I have go 1.20.  I do a git clone and then follow your instructions and it fails and says

type go-licenser
go install<EMAIL_ADDRESS>go: downloading github.com/elastic/go-licenser v0.4.0
go-licenser -license ASL2 -licensor LinDB ./
scripts/addlicense.sh: 9: go-licenser: not found
make: *** [Makefile:45: header] Error 127

I tried to install go-licenser directly and it works but make test still fails.
ballantyne@home ~/lindb (main)$ go install<EMAIL_ADDRESS>ballantyne@home ~/lindb (main)$ go get<EMAIL_ADDRESS>Expected behavior (Required)
make test should pass right?
What's your LinDB version? (Required)
unable to verify install
cd web && yarn start doesn't work either.
error Command "start" not found.

go-licenser: not found
need add  go bin to the PATH environment variable. (https://go.dev/doc/install)
error Command "start" not found
sorry about it, the doc has mistake, you can try run yarn dev for running web dev mode, it dependencies LinDB backend ran and yarn installed.

I got the server to start and the dashboard seems like it works.  I haven't gotten the server to do anything yet because there is no client library and I haven't looked into adding data manually.
https://lindb.io/guide/lin-ql.html
I noticed that you have linql, is there a plan to enable people to use that directly as a language that people can use with a client rather than just as part of the command line interface?  Would that work like a postgres client?  I am interested in learning about that.  Would that just be a tls connection that you can send linql statements?  Would it return json?  csv?  Some other format?  Maybe that is already working?  I haven't gotten that far yet.
Rest
I think that the client libraries that you have must be using http and also possibly rest?  Right?  I was thinking of trying to make one for node.js if i can figure out how your api works.  Do you have a reference that explains the various aspects of how that api works?  I noticed there are something like channels and points?  Points have tags and fields?  Is there a json schema?  What endpoints are there?  Does it work by just sending requests to the host address?  Let me know if you have more information, maybe I will examine the go and java libraries more if you don't have a spec.

LinDB has simple command line client(https://lindb.io/guide/cli.html) like mysql/postgres, but CLI just queries metric data and the state of cluster, because LinDB supports writing data schema-free, so currently not support writing data via CLI;
LinDB CLI build on the rest api(https://lindb.io/api/), and sends LinQL statement will return json result;
Some basic concepts about LinDB data model please ref(https://lindb.io/guide/concept.html);
add new doc to describe how go/java client work(https://lindb.io/guide/client/);


CI: pypi deployment failing

@effigies have you ever seen something like:
Processing ./dist/sdcflows-0.1.0.tar.gz
    ERROR: Complete output from command python setup.py egg_info:
    ERROR: Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-req-build-v9krq8c7/setup.py", line 26, in <module>
        main()
      File "/tmp/pip-req-build-v9krq8c7/setup.py", line 13, in main
        import versioneer
    ImportError: No module named 'versioneer'
    ----------------------------------------
ERROR: Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-req-build-v9krq8c7/

sdist requires a MANIFEST.in. My guess is it's that.

Right, because of that the local versioneer module is not being picked. Very much appreciated.


ERROR: REGISTER_HID: libusb error: Pipe error WARN: Register HID keyboard failed on MacOS

[x] I have read the FAQ.
[x] I have searched in existing issues.

Environment

OS: macOS
scrcpy version: 2.4
installation method: brew
device model: moto g8
Android version: old!

Describe the bug
Screen is smashed so I can't access to enable debugging and tried scrcpy --otg
INFO: USB device found
INFO:     -->       Generic Mass Storage Device

On errors, please provide the output of the console (and adb logcat if relevant).
ERROR: REGISTER_HID: libusb error: Pipe error
WARN: Register HID keyboard failed

scrcpy 2.4 <https://github.com/Genymobile/scrcpy>
INFO: USB device found:
INFO:     -->     Generic Mass Storage Device
ERROR: REGISTER_HID: libusb error: Pipe error
WARN: Register HID keyboard failed

For some reason, libusb does not detect your Android device:
INFO: USB device found:
INFO:     -->     Generic Mass Storage Device

Or maybe it's your device but in mass storage mode (to access the content of the device)? Try disabling this mode on your devife (switch to "charge only").


Typescript header thinks controller is mandatory in Component

Description:
Typescript header thinks controller property is mandatory in Component
Steps to Reproduce:
This (or any other component with only view) is not compiling as TypeScript
var pageMain = {
  view: (w) => {
    return mPage(m("div",  m("span", "Some text") ) )
  }
}

Suggested solution
There should be a question mark after "controller" property ofComponent in mithril.d.ts, like this
	/**
	* This represents a Mithril component.
	*
	* @see m
	* @see m.component
	*/
	interface Component<T extends Controller> {
		/**
		* The component's controller.
		*
		* @see m.component
		*/
		controller?: ControllerFunction<T> | ControllerConstructor<T>;

		/**
		* Creates a view out of virtual elements.
		*
		* @see m.component
		*/
		view(ctrl?: T, ...args: any[]): VirtualElement;
	}

Closing as duplicate of #1336.


tests: hil: add rpc tests

Resolves golioth/firmware-issue-tracker#321

The ESP-IDF RPC sample tests are unstable in this PR. I don't immediately know why that might be, but I'm going to investigate (mostly commenting to remind myself).

The ESP-IDF RPC sample tests are unstable in this PR. I don't immediately know why that might be, but I'm going to investigate (mostly commenting to remind myself).

This is resolved in #400 and is unrelated to the tests introduced here. This PR is ready for review.


feat (tuning): end-to-end supervised fine-tuning for text classification

Description
Thank you for opening a Pull Request!
Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

[ X] Follow the CONTRIBUTING Guide.
[ X] You are listed as the author in your notebook or README file.

[ X] Your account is listed in CODEOWNERS for the file(s).

[ X] Make your Pull Request title in the https://www.conventionalcommits.org/ specification.
[ X] Ensure the tests and linter pass (Run nox -s format from the repository root to format).
[ X] Appropriate docs were updated (if necessary)

Fixes #<issue_number_goes_here> 🦕

Is this PR supposed to be a replacement for #787 ?

@holtskinner I went through all the errors from  lint code base and lint notebook errors and fixed them. The remaining ones make no sense to me. As per spelling errors, the errors are words likeICML (where dataset was published) last names from the authors of the dataset, automl and lopgrobs, which are not spelling errors.

I've added some of the terms to the spelling allowlist. You can see the remaining errors in the summary. It explains what the errors are and what they should be.
https://github.com/GoogleCloudPlatform/generative-ai/actions/runs/10254677291?pr=919

Thanks Holt! All Spelling errors are now fixed. The Lint Notebook and Lint Code errors remain, as I have made different changes but nothing fix them.

I would also recommend putting the methods in the python file in the notebook itself so the users won't need to download another file when using colab.

@holtskinner  fixed all errors and refactored as per suggestions. Erwin has recommended to have the
"migration" functions separately for portability, but overall I agree that having inside the same colab is easier, so just put them back in the notebook as well and deleted the separate file.
Many thanks for all the great feedback. LMK if sth else needs to be changed to finally merge it into main :)


Improve performance of project delete for Windows

Describe the bug
Guppy freezes during project deletion on Windows. Please have a look at the screen recording and the message Keine Rückmeldung means not responding.
I think this is a problem with the deletion of node_modules folder. I'll have a look at the issue and I think it could be improved by using rimraf for delete process.
To Reproduce

Create Project
Delete project from disk

Expected behavior
Delete project with-out freezing.
 I think we could delete the project completely as a project can have over 100 MB with many small files. Or as a compromise delete the node_modules folder and move the rest to trash. I think I'll start with this.

Or as a compromise delete the node_modules folder and move the rest to trash. I think I'll start with this.

That sounds good to me - that way the user can restore a deleted project, and node_modules are easy enough to reinstall (although not really through Guppy... we should add a "reinstall modules" button at some point).

Fixed in #280


Donate Link/Button for Developer

You work so hard on this. How can I donate to you?
I do not want you to feel burned out. I appreciate your dedication.
Please include a donate link on your GitHub page..... Or maybe a small donate Button in the Salt Rim app.

Thanks for the interest but I do this in my free time, and I don't stress about it too much :). I don't really have the need for donations right now, but I'm really glad you are enjoying it!
Thanks for all the feedback!


[Extensions] Background image field doesn't like the letter "p"?

Current Behavior
The following behavior might only occur on the envoy filter component from Istio-base model - at least that is the component used in the example.
https://github.com/meshery/meshery/assets/7570704/931ec433-11b2-49ac-ac66-d65bbd3129ae

Contributor Guides and Handbook

📚 Meshery Build and Release Strategy
🎨 UI Design For Meshery Extensions Figma in Figma (open invite)
📚 Meshery Extensibility Providers
⌨ Meshery API Docs
🙋🏾🙋🏼 Questions: Discussion Forum and Community Slack

@leecalcote Can you help me how to reproduce this? Which component is this actually?

@leecalcote  I would like to work on this issue , can you assign me this issue ?


Problem parsing message object: TypeError: Cannot read property 'image' of null

Hey,
when people send links which get rendered within the chatbox with their open-graph stuff, I am sometimes getting this error.
{ error: 'Problem parsing message object. Please open an issue at https://github.com/Schmavery/facebook-chat-api/issues.',
  detail: TypeError: Cannot read property 'image' of null
    at _formatAttachment (/opt/app/node_modules/facebook-chat-api/utils.js:448:44)
    at attachments.map.v (/opt/app/node_modules/facebook-chat-api/utils.js:502:55)

I am wondering if there would be the possiblity of having a listen method which does not try to parse. I am mainly using it to get threadIDs from the message objects, but it often fails due to the stuff goin gon in utils, this being one example. Is there a better way if I am just interestd in the threadID of incoming messages?

If you used the npm version when getting this error, please try updating and see if you still get this error. We fixed a lot of attachment issues :)


fix: handle marketing deeplinks

This PR resolves MOPLAT-142
Description

Our marketing links use a custom subdomain, click.artsy.net. We want these to open in the app immediately similar to other artsy links so they are added here to associated domains in the iOS app. They are encoded so we need to follow a redirect to get the proper link before doing our standard navigation. Also requires some changes to our universal links files addressed elsewhere. iOS only for now because of more general problems with Android deeplinks.
iOS
Before
https://user-images.githubusercontent.com/49686530/203349550-fd972f9e-bea7-42cd-80af-9cc606e8721e.mov
After
https://user-images.githubusercontent.com/49686530/203349565-af8b3423-65aa-4d29-9cc9-12ab663317f4.mov

NEXT UP

[ ] Fix deeplink problems on Android generally
[ ] Add links to android config
[ ] Add redirect on android

PR Checklist

[x] I tested my changes on iOS / Android.
[x] I added screenshots or videos to illustrate my changes.
[ ] I added Tests and Stories for my changes.
[ ] I added an app state migration.
[ ] I hid my changes behind a feature flag.
[ ] I have prefixed changes that need to be tested during a release QA with [NEEDS EXTERNAL QA] on the changelog.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Changelog updates
Changelog updates

Cross-platform user-facing changes

iOS user-facing changes

Open marketing links immediately in the app - Brian

Android user-facing changes

Dev changes

Need help with something? Have a look at our docs, or get in touch with us.

nice


feat(sqllab): Dynamic query limit dropdown

SUMMARY

Previously, this was a constant of powers of ten from 10 to 100000 and then we tacked on maxRow on the end, being the SQL_MAX_ROW config. This unfortunately results is very confusing behaviour if SQL_MAX_ROW is less than 100,000 as it still let you select 100,000, though wouldn't acctually use that LIMIT, and the messaging would not acknowledge the setting for SQL_MAX_ROW either.
Instead, construct the list by ascending through powers of ten until we reach the configured SQL_MAX_ROW.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

Before

After

TESTING INSTRUCTIONS

Set SQL_MAX_ROW to a value less than 100,000 or greater than 1,000,000
Use the LIMIT dropdown in SQL Lab
Observe that the drop down no longer displays values higher than SQL_MAX_ROW, and will display every power of 10 up to SQL_MAX_ROW

ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Required feature flags:
[x] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

Tagging @justinpark since I see you were the author of this file.


feat(core/EventInfo): add willing_to_attend_in_person field

Types of changes
Thanks for sending a pull request! Please fill in the following content to let us know better about this change.
Please put an x in the box that applies

[x] New feature

Description
Describe what the change is
You don't need to explain HOW you change the code. Your code, including comments in the code should explicitly
self-describe enough about how you change the code.
Steps to Test This Pull Request
Steps to reproduce the behavior:

Go to proposals/tutorial/submit/
Check the displayed page.

Expected behavior
It would appear the field "attending PyCon TW in person" on the creating proposal/tutorial page.
More Information

And I'd like to see someone else contributes to this project 😉

Yeah, we could put the refactoring in the next iteration and let others could join the development.