Implement a policy-settings mechanism for approving/blocking extensions

Hello! We (Trail of Bits Engineering Team) have been asked by one of our clients to contribute a feature to Visual Studio Code, and before we even begin we wanted to introduce ourselves and our plan and get feedback on (or approval for) our plan from the core maintainers of this repo. The proposed changes are to how the editor interfaces with the Extensions Marketplace, so it will only be useful if the changes can be upstreamed. In fact, we may need to coordinate with the VSCode open-source maintainers to even test builds that integrate the Extension Marketplace, present only in Microsoft builds of VSCode. We would appreciate your feedback on how/whether to proceed.
Feature Request
Enhance VSCode with the basic features for extension management:

The ability to define an extension update policy

The policy would include a setting whether to allow side-loading of extensions (as VSIX files)

With this policy, control whether VSCode can install, update, or load/run any given extension

Blacklist by extension ID
Whitelist by extension ID

Pinning an extension to a particular version, allowing its continued use or the installation of that version, but preventing an update
Prevent the use of extensions newer than some specified age (allowing for a “cooling off period” for new or untested extensions)

We plan to implement the extension management policy using an approach modeled on the extension management policy features in Google Chrome (and later by Mozilla, who based the extension management model of Firefox heavily on the one in Chrome), but without (at this time) its concept of a per-extension permissions model.
Deployment of the extension management policy to the managed systems would be handled out-of-band by the system's administrator, but it would be included within or referenced from the user's settings.json file. Right now we're not proposing to add any special controls to the settings editor UI of VSCode for editing this extension management policy. The policy will only be editable as JSON, as many other advanced features in VSCode are currently edited.
We acknowledge that, for the time being, this file is within control of the user. For now, we're going to ignore that (it is tracked in #27972)
Proposed UI changes

Ensure that the VSCode extension UI elements presented to the user explain that an extension is blacklisted by their policy, and/or indicate such with a visual change. User should still be able to see blacklisted extensions in the marketplace, but just have their ability to install them blocked with a message (a configurable message also defined in the policy, with a clickable URL for more information and help), such as “this extension has been blocked by your policy; ask your admin.”
Ensure that the VSCode extension marketplace UI indicates to the user when only certain versions of the extension are blocked. In this case, the installable version should be indicated, and a visual change in the UI should indicate the relevant release notes for that version.

Related Issues

Feature Request: extension permissions, security sandboxing, and update management
#70736

Client sponsor
Our client, who has agreed to participate in this discussion, is @zabicki-stripe

Appreciated for the detailed description of your requirement. To start with, one of the requested features is already supported. Pinning an extension to a particular version, allowing its continued use or the installation of that version, but preventing an update. User can pin to a specific version of an extension. Some of the features are not common and not frequently asked like disabling side loading, cooling off period.
I would say overall it is a big feature and generally not considered for external contribution. But if you are super keen on this, you can think of going with one by one.

Hi Sandeep,
Thank you for that context. It's quite helpful. If we split this into three
contributions (allowlist, denylist, and cooling off period) do you think
that these features would be approved?
Thanks,
Roman
On Mon, Nov 18, 2019 at 4:17 AM Sandeep Somavarapu<EMAIL_ADDRESS>wrote:

Appreciated for the detailed description of your requirement. To start
with, one of the requested features is already supported. Pinning an
extension to a particular version, allowing its continued use or the
installation of that version, but preventing an update. User can pin to a
specific version of an extension. Some of the features are not common and
not frequently asked like disabling side loading, cooling off period.
I would say overall it is a big feature and generally not considered for
external contribution. But if you are super keen on this, you can think of
going with one by one.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/84756?email_source=notifications&email_token=AL6TDYMM4D2TVNYGCUXTVO3QUJTRXA5CNFSM4JNEKII2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEJ5SLQ#issuecomment-554948910,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AL6TDYK2CXLUSGI3BW2JPODQUJTRXANCNFSM4JNEKIIQ
.

Depends on how complex each feature is going to be. But PRs are always welcome.

@sandy081 what would you recommend we do in order to ensure that our contribution is accepted and merged in due time? I see there are many PRs going back several years, so some PRs are not welcome. We just want to know if these are specifically features that would be merged, if we completed a PR.

You can start with

The policy would include a setting whether to allow side-loading of extensions (as VSIX files)

Providing organizational level security is on our 2020 roadmap (Make consumption of extensions more secure...) so this is a good topic, thank you.
As @sandy081 mentions this is a significant feature area that we want to allocate time and resources for to do a comprehensive design and implementation, which makes it difficult right now to accept external contributions.
Per our roadmap, you can expect that we will look at this over the next 6-12 months.

Hello, @chrisdias  my customer is also keen to see this available as they rolled out the ADS in their corp but they want to control what users can install and managed centrally by policies. So that users dont miss use the extensions for data exfiltration or code leakage. Any further update on this would be great as the last comment is 2.5 yr old , i like to know what is the latest.
Thanks

Hello.
I represent a small company 50-100 employees, with an internal development team comprising approx. 10-15 developers, testers and business intelligence users who all use Visual Studio Code. We have two goals that I'd like to address: to obtain a degree of consistency of extensions installed across devices, and the facility to control that centrally. To that end I had the bright idea of creating a feature request only to learn that this request already exists (and has for three years 🙄😄). Nevertheless, I was asked to share our use case here :).
Having an allow-list policy would enable us to limit the set of extensions that can be installed across the workplace in a simple-to-manage manner, however a model similar to Firefox's ExtensionSettings policy would allow us to explicitly control the entire set (noting that only the 'installation_mode' and possibly 'blocked_install_message' properties might be appropriate here).
Firefox example
{
  "*": {
    "blocked_install_message": "Custom error message.",
    "install_sources": ["https://yourwebsite.com/*"],
    "installation_mode": "blocked",
    "allowed_types": ["extension"]
  },
<EMAIL_ADDRESS>{
    "installation_mode": "force_installed",
    "install_url": "https://addons.mozilla.org/firefox/downloads/latest/ublock-origin/latest.xpi"
  },
<EMAIL_ADDRESS>{
    "installation_mode": "allowed"
  }
}

Possible VS Code example
{
  "*": {
    "blocked_install_message": "This extension has been blocked by your organisation.",
    "installation_mode": "blocked"
  },
  "ms-python.python": {
    "installation_mode": "force_installed"
  },
  "vscodevim.vim": {
    "installation_mode": "allowed"
  }
}

To date we have addressed our requirements by installing extensions to a non-user-writable location and setting the (undocumented - I believe) VSCODE_EXTENSIONS environment variable to point to that folder - but this is brittle at best.
Thanks for your time.

I created a duplicate issue ( https://github.com/microsoft/vscode/issues/170840 ), I'll bring what I wrote there to this discussion.

As the VSCode marketplace does not seem to be sufficiently regulated from a security point of view:

https://www.bleepingcomputer.com/news/microsoft/vscode-marketplace-can-be-abused-to-host-malicious-extensions/
https://devclass.com/2023/01/09/researchers-demonstrate-a-thousand-installs-of-fake-vs-code-extension-in-48-hours/

It would be great with ADMX policies for specifying extension policies, like:

Allowed sources (VSCode Marketplace vs. other marketplaces (?) vs. sideload).
Preaccepted extensions / whitelist:

A list of extensions from a source that are allowed to be installed.
Maybe even preaccepted publishers, like Microsoft, to make the management overhead smaller.

ATM, update mode seems to be the only thing one can control with VSCode.
 This previous comments reads as though it was actively being looked at being placed on the roadmap, is that still the case?

Its 2024, is there an update on this? This is a security issue that needs to be addressed.

Here two years later, I see it was accepted onto the backlog but can we get a timeline as to when this will be out or if it is already available

Is there any priority for this feature? Malicious plugins are a great security risk for our company and we have no way to combat this, short of not allowing VSCode as an installation on our development teams machines.

@xNarnia until something better gets implemented can you use the information at https://code.visualstudio.com/docs/setup/network#_common-host names to block all extension installation direct from Marketplace?

Posting to add further weight to the urgency of this:
https://www.bleepingcomputer.com/news/security/malicious-vscode-extensions-with-millions-of-installs-discovered/amp/
"Microsoft's lack of stringent controls and code reviewing mechanisms on the VSCode Marketplace allows threat actors to perform rampant abuse of the platform, with it getting worse as the platform is increasingly used."

This feature request is on our roadmap and I expect it to land in the next 6 months.

Is there any priority for this feature? Malicious plugins are a great security risk for our company and we have no way to combat this, short of not allowing VSCode as an installation on our development teams machines.

You do have another option when you are in control of the installations: drop the marketplace entry points from product.json or replace them to an endpoint you control, for example an OpenVSX instance uploading only the extensions there that are validated.
Especially when dropping the endpoint and controlling the installations of vscode, you may want to extract extensions into the vscode installation (below resources\app\extensions) - they will be shown as builtin and work fine.
Of course this only works if you prevent installing from vsix - @isidorn a setting in product.json to prevent that (both from command line and from UI) would be very useful.

To add some fuel to the fire:
https://medium.com/@amitassaraf/the-story-of-extensiontotal-how-we-hacked-the-vscode-marketplace-5c6e66a0e9d7

It would be very nice if we could whitelist extensions by author. So we could for example whitelist all extensions by Microsoft.

We use devcontainer.json to have several extensions pre-installed. It would be nice to forbid users installing extensions in general without breaking installation at Devcontainer build time.

Is there any update on this? What are folks doing to prevent developers from installing bad extensions from the marketplace today?

My last comment still holds true https://github.com/microsoft/vscode/issues/84756#issuecomment-2157964224
We are aware of this, and I expect us to have something in the next couple of months.

That is great, thanks @isidorn for the response, looking forward to testing out this feature.

Users that up-voted or commented on this issue - can you please provide details on how you would like this feature to work exactly?
Let's imagine that we introduce a setting extensions.allowList. This setting could be a map of "extension ID" to array of allowed extension versions. Example
extensions.allowList: {
   "eamodio.gitlens": ["2024.10.2505", "2024.10.2502"]
}

All extensions not on this list would be disabled for running/installing.
Would this work? If not what other requirements do you have?

Is there a need to say "allow all versions of an extension"?
Is there a need to say "allow all versions higher than a specific number"
Is there a need to say "allow all extensions from a specific publisher"
...

Please share your exact use case with us, as that would help greatly. Thank you!
Step 2 is making this setting policy controlled.

Would this work? If not what other requirements do you have?

How about allowing/blocking extensions access to specific permissions (e.g. network access, system files...)

@ssheep thanks, but completely unrelated to this issue. There are other feature requests for that. Please search our repository.

@ssheep I believe that's https://github.com/microsoft/vscode/issues/52116

All extensions not on this list would be disabled for running/installing.
Would this work? If not what other requirements do you have?

Yes, that would work. One big open question, because this is planned as policy: How would you ensure that a user cannot override it?
Of course that list should apply for all of "marketplace", "from vsix inside vscode" and "from vsix using the command line".
I do suggest a single string per extension entry though, while allowing to start an element with ">=" (or <) and keep multiple entries comma separated in that list (same format as the npm dependency list).
Also: blocking extensions [or specific versions of it] (is missing and also was requested). That could either be done using the same single string starting with an exclamation mark - "!*" would then block all versions, `"!2024.10.2505, !2024.11.*" all that match (but that could be "nice, not really needed" as well) - or be done with a counter setting (that would weight more that the approve list),

Is there a need to say "allow all versions of an extension"?

Yes, but if you don't want a "*" value, one could work around this using ">0".

Is there a need to say "allow all versions higher than a specific number"

Yes, to work around versions found as buggy.
Ideally those are then also grayed out in the not shown in the "Install specific version..." popup.

Is there a need to say "allow all extensions from a specific publisher"

Yes, especially for company publishers. The easiest way is to say "eamodio.*": "*". Note that this should be able to override for specific extensions [non-wildcard wins if both match] (like "all from that publisher, but this single one needs to be at least that version".

Hi @isidorn!
We at Stripe are very excited to see movement on this ticket, and are happy to share our perspective.
Our final use case is to be able to restrict which extensions engineers are able to run to an allowlist of specific versions, which is what we use for other software repositories (NPM, bundler, etc). There are a few Stripe-controlled extensions that can be trusted at any version, and we may also want to allowlist all versions of Microsoft-published extensions to reduce VS Code update churn.
But getting to that point will require a migration, which will benefit from being able to set a more relaxed policy at first (allowlist all versions of specific extensions) that we can later ratchet into its tighter, more controlled form (allowlist extensions at specific versions).

Is there a need to say "allow all versions of an extension"?

We would find this capability useful. We have some one-off extensions that are not Stripe published, but that we would be willing to keep on the "cutting edge".
This would also be a nice feature for the transition to explicitly delineated versions for Marketplace extensions. For example, we may choose to allow all versions of the extensions currently in use at Stripe, and then ratchet it down to specific versions over time, to avoid any big-bang issues from the rollout.

Is there a need to say "allow all versions higher than a specific number"

There are some extensions that cause severe issues in our monorepo on older versions, and we have bespoke tooling to uninstall them if they are found. It would be great to be able to translate this into the VS Code policy.
I can also envision scenarios where a Stripe-published extension, which we want to allowlist for all new versions, causes problems on older versions.

Is there a need to say "allow all extensions from a specific publisher"

It would be nice to be able to allowlist all Stripe-published extensions and all Microsoft-published extensions. I could imagine it causing a lot of toil to maintain a Microsoft-published-extensions allowlist.
I cannot think of any other capabilities that we would require. While we have the ability to express constraints like "uninstall extension versions greater than version x" in our current bespoke system, we wouldn't need to express these policies in this new allowlist design because the denylist is implicit: If it's not on the allowlist, it's not allowed.
We do have specific opinions on how this system should reconcile violations. For example, if a user is on version 1.0 of a marketplace extension, and we change the allowlist to version 1.1, it would be nice if that forced an upgrade of the extension.
Let me know if you have any further questions!

👋 Happy to share my perspective as well from Anthropic!
Our strongly preferred solution would be an internal mirror akin to Artifactory where we can completely control the extensions available, and configure VSCode to only pull from there.  This gives us a much stronger security posture, and a lot of questions around versioning are somewhat moot - if we don't want an extension running we won't mirror it, if we don't want a version we don't mirror it.
Beyond that my views are largely aligned w/ @jvilk-stripe's.  One other aspect I would add is I would prefer if extensions were a range (e.g. > some version, <= another).  We unfortunately semi-frequently get broken by pylance updates and we have no recourse other than to send out a Slack blast with instructions on how to downgrade.

Options
"allow all versions of an extension"?
and
"allow all extensions from a specific publisher"
are defintely needed.
Specific versions is not particularly usefull for us, development speed of VSC and it's extensions is high

Great feedback, thank you 🙏
If there are others do please share your company name and the scenarios you would like this feature to tackle.
Regarding internal mirror - this is a separate ask that will not happen in next 12 months. More details here: https://github.com/microsoft/vscode/issues/21839

Please also implement a blocklist with higher precedence than the allowlist.
So we could implement allow "microsoft" but block "AI-extension-xyz"

I would go with the same addin settings that exist for Edge
Allow or block extensions
Force-install an extension
Block extensions from a specific store or update URL

We at ClassWallet are also very excited to see movement on this.
We would primarily configure this as an allow list with 'any version of a specific extension'. Version ranges might be useful if you feel like coming up with a syntax that says things like 1-5,7+ (ie. not version 6). If that's too much, a minimum version is probably most useful and the way to go.
We're unlikely to ever set it up the other way with allow everything but block XYZ. Especially if we have version ranging above.
Publisher wildcards is not a feature we'd use, but I can see it being useful in certain compliance scenarios.
Force install would be incredibly useful.
Anything not matching the current allow policy is just disabled upon startup. Can't allow existing extensions to keep working if not compliant. Be nice to customize a message to display on both the extension add page, and on startup if things are being managed/disabled, so devs know who controls it at an org.
Thank you!!!

Thank you very much for your feedback. We have been discussing this in the team today, and I have follow-up questions. Helping us figure this out by answering would be great!

Is the blocklist really needed in your company? If yes, can you provide examples of extensions that you would put on the blocklist?
What OS are your developers using?

We have a two proposals for a potential solution - they were inspired by our current files.exclude setting in vscode, and how gitignore works. I wonder what are the thoughts, and if there are preference towards either of these.
It would be good if you try to use these syntax to specify what you would actually put in this setting if it were available today. And then we can see what looks like a more elegant solution. We will not support both of these - we must choose one!

`extensions.blockList` - setting that is an array of strings
You specify what extension need to be blocked. With ! you specify what extensions are allowed.

## Example 1: only allow specific versions of python
## Explanation: all extensions are enabled (since they are not on the blocklist), and for python we disable all versions with the * wildcard, and then allow only the specific version < 3.1.4 and 2.0.0
ms-python.python-*
!ms-python.python<3.1.4
!ms-python.python-2.0.0

## Example 2: allow ONLY python 3.1.4
## Explanation: with * we disable all extensions, and specifying !ms-python.python-3.1.4 we allow only this specific version of the extension
*
!ms-python.python-3.1.4

## Example 3: disallow antythign from figma
figma.*

## Example 4: allow only MS extension. Disallow all other extensions
## Explanation: with * we disable all extensions, and with !microsoft.* we allow all microsoft extensions
*
!microsoft.*

## Example 5: disallow specific single extension
## Explanation: all extensions are allowed, except github.copilot (all versions of it)
github.copilot

## Example 6: disallow extension version range
## Explanation: all extensions are allowed, except pylance >= 3.1.2
ms-python.pylance>=3.1.2

`extensions.allowList` - setting that is an array of strings
You specify what extension need to be allowed. With ! you specify what extensions are blocked.
What is not on the list is blocked.

## Example 1: only allow specific versions of python
## Explanation: with * we allow all extensions, with !ms-python.python we block all python versions, but with >=3.1.4 and 2.0.0 we allow those specific python versions
*
!ms-python.python *
ms-python.python >=3.1.4
ms-python.python 2.0.0

## Example 2: allow ONLY python 3.1.4
## All other python versions will be blocked. No other extensions are allowed.
ms-python.python-3.1.4

## Example 3: disallow antythign from figma
*
!figma.*

## Example 4: allow only MS extensions
microsoft.*

## Example 5: disallow specific single extension
## Explanation: all extensions are allowed with a *, except github.copilot with !
*
!github.copilot

## Example 6: disallow extension version range
## Explanation: we allow all extensions with a *, and then with !ms-python.pylance we block all verisions of pylance >= 3.1.2
*
!ms-python.pylance>=3.1.2

Blocked extensions will not be able to be installed. Will appear as disabled on startup. If there is a newer version of the extension that is allowed, there will be an update button so devs can click it. There will be no force update in first version.

Hey there, answering for Stripe.

Is the blocklist really needed in your company? If yes, can you provide examples of extensions that you would put on the blocklist?

I have an example, which may be expressible via the existing allowlist primitives.
Let's say we have a policy to trust all Microsoft published extensions, because we trust Microsoft and do not want the KTLO burden of updating allowlists for all of the VS Code internal extension. But then, hypothetically speaking, Microsoft launches a new extension that sends or reveals source code to a centralized server to provide a developer service, like autocomplete. This extension would not be allowed for use at Stripe, because we do not allow our source code to leave our premises without a security audit of the destination/etc.
We may want to block that extension, but I imagine we could do so by expressing the policy:

Allowlist all by Microsoft
Allowlist the empty set of versions for this specific Microsoft extension

What OS are your developers using?

All Stripe engineers use MacBooks for development. We use a mix of local and remote development. For remote development, the remote host is running Ubuntu Linux on a supported LTS version.

OK, Stripe has a light preference for an allowlist, since we want to block all extensions by default and will be maintaining an allowlist internally. But the proposed blocklist approach makes this possible with the * and the !allowlisted-extension-id syntax and would be workable.

Blocked extensions will not be able to be installed. Will appear as disabled on startup. If there is a newer version of the extension that is allowed, there will be an update button so devs can click it. There will be no force update in first version.

Can we customize the message/string that appears when a user is searching for extensions in the Marketplace? We will have approval workflows for adding new software to the allowlist. We would love to be able to direct users to a helpful webpage where they can request the extension they want to install to reduce developer friction/frustration.
Similarly, if a new version is available but update is disabled, we would like to show this message.

It would be good if you try to use these syntax to specify what you would actually put in this setting if it were available today.

For the allowlist, the first change would list all of the extensions currently in use today at all versions. We would probably blanket approve all stripe.* and microsoft.* extensions. Provided that goes smoothly, we would potentially audit the list and annotate extensions with the specific versions in use.
For the blocklist, we would block all, and then unblock the things I previously mentioned.

Thank you, this is super useful!
Would love to hear from others @CW-Willow @StephanGa @rowillia

Speaking for ClassWallet,
We wouldn't use a blocklist ever. I don't know of a security framework that
likes allow-all-except approaches, but we're up to our necks in StateRamp
here. I can see it being useful at some companies where there's a 'bad'
extension in the news that's a threat that you might want to dig out, but
what about the other million on the store? If you're going to the trouble
of managing endpoints and policy centrally, you're probably going
deny-all-except every time.
Version control might be a good/better remedy if there's a dangerous
version of something, but it's probably better solved by forcing an upgrade
(or other mitigation for a while). As I mentioned before, if you can get
super granular over versions, great, but it's not a huge deal; minimum
version is fine for CW. Force install option of the latest version (per
extension) becomes very useful as a check on startup occasionally.
All in all, what Chrome/Edge does with its extensions when you enable
management is pretty much what's desired: Allowlist, minimum version, force
install option.
I'd like to reiterate the additional ask to be able to customize messages
on the store if managed, and at startup for the user if something is
disabled. Save a lot of pain to the support desk.
We're a Windows shop. Intune.
Hope it helps. Thanks,
~W
On Thu, Oct 31, 2024 at 3:00 PM Isidor Nikolic @.***>
wrote:

Thank you, this is super useful!
Would love to hear from others @CW-Willow https://github.com/CW-Willow
@StephanGa https://github.com/StephanGa @rowillia
https://github.com/rowillia
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/84756#issuecomment-2450616875,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A2HVOR2QCZ3BCRLNPPDHBL3Z6J44LAVCNFSM4JNEKII2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TENBVGA3DCNRYG42Q
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Willow Nice
Chief Security Officer
ClassWallet
https://us.content.exclaimer.net?url=http%3A%2F%2Fwww.classwallet.com%2F&tenantid=Y7Gw8DgHEeyYIAANOhMDEQ&templateid=891d51bbc21eef1186d46045bdd55b16&excomponentid=Q_HEhMmktsj8z8mA1RiH1aM-FitsCJzlaf2dmGrPkvI&excomponenttype=Link&signature=gxeUJyQiNUAguQ8p8yeJBw9iTD0LwcaFq8bsrWd9_Png-EmQ4b4AXFa9zJplOXhxPWta6dTc1BfDu0yNu97o5AcRe_cm2Deum2Iu2WhGGHFOV6ILPsrot9Kc9ZLwlK7yHVh2JXAJZRMWejanVjgMG8itymJbeWFzXsaNkXOcPQTklU3q02T0z3j_JbVbHisZv-wHE7sY2haKiL0srflZdBugAdjnBkDDzcx3jd3UIHYW1hbP_GKJdDOCo9Tc1sems4eMVjQMZRjczhexQ7RPbGRD_ZzO5VfxfSsPZXE3VkNgwzaNdKGSmi9WbkOhuOASHWEfYXMHr072IkLv6UDpPg&v=1
t.  (954) 536‑8061
e.  @.***   |
w.
classwallet.com

[Yeah, that got chewed nicely by GitHub email, sorry]
Speaking for ClassWallet,
We wouldn't use a blocklist ever. I don't know of a security framework that likes allow-all-except approaches, but we're up to our necks in StateRamp here. I can see it being useful at some companies where there's a 'bad' extension in the news that's a threat that you might want to dig out, but what about the other million on the store? If you're going to the trouble of managing endpoints and policy centrally, you're probably going deny-all-except every time.
Version control might be a good/better remedy if there's a dangerous version of something, but it's probably better solved by forcing an upgrade (or other mitigation for a while). As I mentioned before, if you can get super granular over versions, great, but it's not a huge deal; minimum version is fine for CW. Force install option of the latest version (per extension) becomes very useful as a check on startup occasionally.
All in all, what Chrome/Edge does with its extensions when you enable management is pretty much what's desired: Allowlist, minimum version, force install option.
I'd like to reiterate the additional ask to be able to customize messages on the store if managed, and at startup for the user if something is disabled. Save a lot of pain to the support desk.
We're a Windows shop. Intune.
Hope it helps. Thanks,
~W

The second example - allowList with negation - is totally fine. And if one really would want, this can be used as blockList as well
allow all

block all from bad and copilot
!bad.*
!github.copilot

Great feedback, thank you!
Let's wait until Monday so more feedback trickles in, and then we will propose the solution that we will work on in the Nov milestone.

[...] One big open question, because this is planned as policy: How would you ensure that a user cannot override it?
Of course that list should apply for all of "marketplace", "from vsix inside vscode" and "from vsix using the command line".

That's still open and unclear to me.
If you add that as a normal setting, then any user code override it.
Obviously: if someone has the option to use a portable version of vscode, then that a policy.json won't apply any more.
If you add that to product.json, then this applies only to environments that are installed as system-install (expecting that users don't have the right to update it). If that is done, then a policy.json or similar should be used, because product.json is overwritten on updates. ... but come to think of it - a "system provided additional product.json that is merged" last (similar to #129764 which even could be integrated as well to solve another issue)" could help - if the system-provided comes "last" it may solve both issues (a user could never override that, even with portable versions and it could stay at one single place which is commonly not user-writable).

@GitMensch https://code.visualstudio.com/docs/setup/enterprise#_group-policy-on-windows
So this would first only be allowed on Windows through group policy. But we would add macOS support in the next couple of milestones.

So this would first only be allowed on Windows through group policy.

:-(
But from your link the effect is the right thing and it is reasonable to use the group policies on Windows (even though I don't need to handle those any more myself). With the effect on the client side "overriding settings defined anywhere" I get that this would also work as expected with those clients connecting to GNU/Linux over SSH. Is that so?
Are the existing PolicyDefinitions online anywhere?
I hope that, as soon as macOS support is added, this may also work on GNU/Linux clients. It should easily work the same way if this would be handled via files.

Looking forward to this, as this is a capability we need for our client.
I do not feel we need an explicit deny list in our case. Blocked by default and only allowing extensions in the allowlist is sufficient.

Is there a need to say "allow all versions of an extension"?

Yes.

Is there a need to say "allow all versions higher than a specific number"

Yes. To ensure extensions with critical vulnerabilities aren't installed.

Is there a need to say "allow all extensions from a specific publisher"

Yes. This would be helpful for trusted publishers like Microsoft

On specifying versions, using npm semantics would be helpful. It's already well defined.

version - match exactly
~version - allow patch upgrades
^version - allow minor upgrades
>version - greater than
and so on...

If existing extensions no longer meet the requirements due to a policy update the extensions should be disabled, uninstalled, or updated automatically.

Thank you all for your great feedback! @sandy081 and me iterated on this, and we came up with the following proposed structure
"extensions.allowed": {

        // Allow all extensions from microsoft publisher. If the key does not have a . that means it is a publisher id
        "microsoft": true,

        // Allow all extensions from github publisher
        "github": true,

        // Allow prettier extension
        "esbenp.prettier-vscode": true,

        // Do not allow docker extension
        "ms-azuretools.vscode-docker": false,

        // Allow only versions 3.0.0 of the eslint extension
        "dbaeumer.vscode-eslint": "3.0.0",

        // Allow versions "3.0.0", "4.2.3", "4.1.2" of the figma extension
        "figma.figma-vscode-extension": ["3.0.0", "4.2.3", "4.1.2"]

        // Allow versions "5.0.0" on win and mac of platform specific rust extension
        "rust-lang.rust-analyzer"<EMAIL_ADDRESS><EMAIL_ADDRESS>
        // Allow only stable versions from vscode-pull-request-github publisher
        "github.vscode-pull-request-github": "stable",

        // Allow only stable versions from redhat publisher
        "redhat": "stable",
    }

All extensions not listed here would not be allowed.
Notice the following:

We decided to not support extensions ranges since we believe that is asking for trouble. An extension author can always publish a new version in the range, that might not be approved by your enterprise. So each version has to be explicitly listed
We are supporting specifying platform specific versions using the @ notations. This will give your companies exact control over the allowed extension version
If the key does not have a . we treat it as a publisher, and the rule applies for all extensions from that publisher
The more specific key wins. So "microsoft": true and "microsoft.cplusplus":false all Microsoft extenions will be allowed except C++
For the Windows group policy - the value set there will be this object json stringified.

You can also try it out with VS Code Insiders from next week, to see the full experience.
Please let us know what you think, and if this would work for your organization.
Thank you 🙏

For the Windows group policy - the value set there will be this object json stringified.
Please provide a validator

That's a good result, thanks for updating this issue as well. The additional (stable/platform) is also nice.
I personally still feel that either a range or a >= / + option is necessary. The main reason is that I don't have the time to monitor and review dozens of extension updates, so they will either not be allowed for quite some time or I'm going to set those extensions to "true" instead.

At Stripe, we approve of this design; it meets our requirements.
I did have one additional thought on a different matter. Previously, we discussed wanting to be able to configure the message or URL that appears in the marketplace for blocked/unapproved extensions. It would be really cool if this message or URL could be templated with the extension ID and version so that we can link directly to a filled out internal approval form.

Great work! You solved a lot potential security issues with this!
Only thing that still requires manual work is ensuring security patches are applied by updating the allowed version. Would it be possible to have a "latest" option? Or is that implied when using "true"?
Alternative I would create a script to update the whitelist automatically, e.g. weekly, is there a good API at the extension server for this?

Thank you very much for your feedback.
@ckrueger1979 the validator will basically be admin can paste the JSON string in the settings.json file on his machine. If there are no errors, it is good.
@GitMensch what company are you representing? Does your company have security concerns about a publisher deploying an extension version in your range that you did not review?
@jvilk-stripe Let's take that a separate feature request on top of this. Can you please file a new issue in this repo and ping me @isidorn on it
@janssen92 no, using "true" does not mean latest, it just means any extension version is allowed. Would "latest" mean "latest release version of the extension", or "any latest version of the extension including pre-release".

If this considers both stable (latest stable) and true (latest anything), then this would be ok - but I'd still suggest to keep this in one place, adding "latest-stable" and "latest" to the version options.
Am 22. November 2024 10:35:41 MEZ schrieb Isidor Nikolic @.***>:

@janssen92 discussed a bit with @sandy081 and we think this can be achieved by us making extensions.autoUpdate also group policy controlled. That way by putting "true" and autoUpdate to on, all the developers will be auto updated to latest extension version. Would that work?
--
Reply to this email directly or view it on GitHub:
https://github.com/microsoft/vscode/issues/84756#issuecomment-2493325393
You are receiving this because you were mentioned.
Message ID: @.***>

Working in the banking sector...
And "no", if there's a range configured then this range would be already considered "checked" - possibly there wouldn't be too many extensions configured "open" (themes likely would as they cannot do any harm... or can they "phone home"?)

Hello, is there a concrete time table when this "feature" will be released? I find it a little bit hard to understand what the current status is. There are many links to other issues. Can someone summarize the current situation?

Thank you a lot for the super fast feedback. Is there already a template ADMX file available so I can get familiar with it?

This feature will be released in VS Code Insiders this week. In VS Code stable start of December. Group policy control for now only works in Windows. MacOS group policy support will be released Feb-March/

Is there a timeline for linux support?

Is there a timeline for linux support?

Right now - no. If you need linux group policy support it would be awesome if you create a new feature request and ping me on it. Then we can see how many enterprises need linux group policy support, and that will help us when we figure out prioritization.

Is there already a template ADMX file available so I can get familiar with it?

I am not sure the format of ADMX files, but this setting will just be JSON.stringify of what I proposed above.

You're quick with the responses, @isidorn . Thanks very much, greatly appreciated.

I tested it briefly using the insiders build. I managed to successfully block a provider.
I'm not an expert on how to handle ADMX file. So do I need to change the file before I use Group Policy Management Console on the domain controller to set the list of allowed extensions or do i simply import the file and then set the value in the Group Policy Management Console?

Should be live on our docs webpage https://code.visualstudio.com/docs/setup/enterprise this week

Confirming that the docs for configuring extension allowlists are live.

@ntrogh thank you!
Folk on this issue - let us know if there is something that the docs did not cover, and any other feedback you might have after using this feature (that is now launched and available in VS Code Stable).

LGTM in general.
Some feedback: t1he part "application setting" in https://code.visualstudio.com/docs/setup/enterprise#_configure-allowed-extensions got me confused, because for me that's quite different to "device management" (which is different per OS as well).
The biggest part under https://code.visualstudio.com/docs/setup/enterprise#_device-management that is unclear to me is how (if at all) those settings are taken into account for remote hosts. For example installing on a local REH after connecting to a Linux machine from command line is a server-side only part at first. Is the allow-list then still taken into account and some extensions possibly not loaded from the Windows Client when connecting?

Good feature to finally be available. We've actually already have full discovery, governance, and risk for extensions for VSCode as part of our enterprise solution, and for all other IDEs. If you want this feature as a full solution I recommend checking extensiontotal.com 🥇


[Event Request] Codeunit 12 "Gen. Jnl.-Post Line" OnBeforeCalcPmtDisc

Dear ALAppExtensions team,
On behalf of 4PS I would like to request integration event 'OnBeforeCalcPmtDisc' to be changed in procedure 'CalcPmtDisc' in codeunit 12 "Gen. Jnl.-Post Line".
    local procedure CalcPmtDisc(var NewCVLedgEntryBuf: Record "CV Ledger Entry Buffer"; var OldCVLedgEntryBuf: Record "CV Ledger Entry Buffer"; var OldCVLedgEntryBuf2: Record "CV Ledger Entry Buffer"; var DtldCVLedgEntryBuf: Record "Detailed CV Ledg. Entry Buffer"; GenJnlLine: Record "Gen. Journal Line"; PmtTolAmtToBeApplied: Decimal; ApplnRoundingPrecision: Decimal; NextTransactionNo: Integer; FirstNewVATEntryNo: Integer)
    var
        PmtDisc: Decimal;
        PmtDiscLCY: Decimal;
        PmtDiscAddCurr: Decimal;
        MinimalPossibleLiability: Decimal;
        PaymentExceedsLiability: Boolean;
        ToleratedPaymentExceedsLiability: Boolean;
        IsHandled: Boolean;
    begin
        IsHandled := false;
        OnBeforeCalcPmtDisc(
            //NewCVLedgEntryBuf, OldCVLedgEntryBuf, OldCVLedgEntryBuf2, DtldCVLedgEntryBuf, GenJnlLine, PmtTolAmtToBeApplied, IsHandled); //old
            NewCVLedgEntryBuf, OldCVLedgEntryBuf, OldCVLedgEntryBuf2, DtldCVLedgEntryBuf, GenJnlLine, PmtTolAmtToBeApplied, IsHandled, //new
            ApplnRoundingPrecision, NextTransactionNo, FirstNewVATEntryNo, AddCurrencyCode); //new
        if IsHandled then
            exit;

    //[IntegrationEvent(false, false)] //old
    //local procedure OnBeforeCalcPmtDisc(var NewCVLedgEntryBuf: Record "CV Ledger Entry Buffer"; var OldCVLedgEntryBuf: Record "CV Ledger Entry Buffer"; var OldCVLedgEntryBuf2: Record "CV Ledger Entry Buffer"; var DtldCVLedgEntryBuf: Record "Detailed CV Ledg. Entry Buffer"; var GenJnlLine: Record "Gen. Journal Line"; var PmtTolAmtToBeApplied: Decimal; var IsHandled: Boolean) //old
    [IntegrationEvent(true, false)] //new
    local procedure OnBeforeCalcPmtDisc(var NewCVLedgEntryBuf: Record "CV Ledger Entry Buffer"; var OldCVLedgEntryBuf: Record "CV Ledger Entry Buffer"; var OldCVLedgEntryBuf2: Record "CV Ledger Entry Buffer"; var DtldCVLedgEntryBuf: Record "Detailed CV Ledg. Entry Buffer"; var GenJnlLine: Record "Gen. Journal Line"; var PmtTolAmtToBeApplied: Decimal; var IsHandled: Boolean; ApplnRoundingPrecision: Decimal; NextTransactionNo: Integer; FirstNewVATEntryNo: Integer; AddCurrencyCode: Code[10]) //new
    begin
    end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 51064.


Replace OCP charges API with costs

Replaces reports/openshift/charges API with reports/openshift/costs
Fixes https://github.com/project-koku/koku-ui/issues/591

Codecov Report

Merging #592 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #592   +/-   ##
=======================================
  Coverage   82.18%   82.18%
=======================================
  Files         194      194
  Lines        2987     2987
  Branches      496      496
=======================================
  Hits         2455     2455
  Misses        474      474
  Partials       58       58

Impacted Files
Coverage Δ

src/api/ocpReports.ts
80% <ø> (ø)
:arrow_up:

src/api/ocpOnAwsReports.ts
82.35% <ø> (ø)
:arrow_up:

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 7484046...0bef237. Read the comment docs.


Apply button

This adds the apply button for #12.  It does require changing the json files to include the autoApply field.  This field should be True for most datasets and False where manual applying is desired.  Right now almost everything is manually applied... we may want to revisit this since ParaView only manually applies things that cause filters to re-execute.
@jourdain

I updated this so that the apply button is not used for several of the properties that ParaView doesn't use it for.  Almost ready to merge it.

ok, later this week we will have to synch up as I'm migrating the code in tonic-[ui,io,core] into a new paraviewweb repo. In that process, I'm refactoring quite a lot. So when I'm ready, you should start using paraviewweb inside LightViz as dependency instead of tonic-ui and tonic-io.
But will let you know once available... ;-)

Yes, let me know when those changes are available.  I've fixed a couple more minor things with this and it is about ready so I'm merging it now.


Python error when install the integration

Hello!
I have just installed the integration and some python errors appears in hass log.
I tried to use release 0.6.4 and also 0.7.0b1. Still same error.
I am running HA 2024.12.4
hass-1  | 2024-12-22 17:27:51.913 WARNING (MainThread) [homeassistant.util.loop] Detected blocking call to open with args ('/root/.netrc',) inside the event loop by custom integration 'cz_energy_spot_prices' at custom_components/cz_energy_spot_prices/spot_rate.py, line 94: async with session.post(self.OTE_PUBLIC_URL, data=query) as response: (offender: /usr/local/lib/python3.13/netrc.py, line 74: with open(file, encoding="utf-8") as fp:), please create a bug report at https://github.com/rnovacek/homeassistant_cz_energy_spot_prices/issues hass-1  | For developers, please see https://developers.home-assistant.io/docs/asyncio_blocking_operations/#open hass-1  | Traceback (most recent call last): hass-1  |   File "<frozen runpy>", line 198, in _run_module_as_main hass-1  |   File "<frozen runpy>", line 88, in _run_code hass-1  |   File "/usr/src/homeassistant/homeassistant/__main__.py", line 227, in <module> hass-1  |     sys.exit(main()) hass-1  |   File "/usr/src/homeassistant/homeassistant/__main__.py", line 213, in main hass-1  |     exit_code = runner.run(runtime_conf) hass-1  |   File "/usr/src/homeassistant/homeassistant/runner.py", line 154, in run hass-1  |     return loop.run_until_complete(setup_and_run_hass(runtime_config)) hass-1  |   File "/usr/local/lib/python3.13/asyncio/base_events.py", line 708, in run_until_complete hass-1  |     self.run_forever() hass-1  |   File "/usr/local/lib/python3.13/asyncio/base_events.py", line 679, in run_forever hass-1  |     self._run_once() hass-1  |   File "/usr/local/lib/python3.13/asyncio/base_events.py", line 2027, in _run_once hass-1  |     handle._run() hass-1  |   File "/usr/local/lib/python3.13/asyncio/events.py", line 89, in _run hass-1  |     self._context.run(self._callback, *self._args) hass-1  |   File "/config/custom_components/cz_energy_spot_prices/spot_rate.py", line 106, in get_electricity_rates hass-1  |     return await self._get_rates(query, unit, has_hours=True) hass-1  |   File "/config/custom_components/cz_energy_spot_prices/spot_rate.py", line 133, in _get_rates hass-1  |     text = await self._download(query) hass-1  |   File "/config/custom_components/cz_energy_spot_prices/spot_rate.py", line 94, in _download hass-1  |     async with session.post(self.OTE_PUBLIC_URL, data=query) as response:

It seems to be complaining about /root/.netrc file. Do you have such file on your system? What's the file content?

I check it twice but I dont have this file neither in system nor in hass docker container..


What's the reason for having a json and xml part?

While thinking about module's parts in general (see https://github.com/Codeception/Codeception/issues/6026), one thing is still unclear: What's the reason for having the two parts in this module? Are there really situations where loading the entire REST module would lead to a conflict?
And what does it mean that e.g. at https://codeception.com/docs/modules/REST#amBearerAuthenticated both parts are listed? That you'll get this method if you load part json or xml or the entire module (i.e. no part key given at all)? => This is inconsistent with https://codeception.com/docs/modules/Symfony where part is not mentioned for most functions.

I remember that the idea was that if somebody is testing webservice which returns JSON, they don't need XML methods and vice versa, but they both need amBearerAuthenticated and other action methods.
Including only methods you need reduces size of autogenerated Actor class and that should have some positive effects.

and that should have some positive effects.

On speed? The question is if that's worth it...
In total, I'm suggesting to drop those two parts here, for the following reasons:

Consistency: Right now, I'm trying to explain the "part" system in the docs, as a means to prevent compatibility problems - see https://github.com/Codeception/module-webdriver/pull/33. But this is not true for the REST module: Here, the same thing (parts) is used for a different goal (speed).
Effectiveness: I'm counting 9  XML-related methods at https://codeception.com/docs/modules/REST. And I can't believe that the additional complexity (one more thing to pay attention) is worth the (minimal) benefit of reducing the generated actor classes by just 9 methods.

I mean, it's the nature of a library that not everybody is using every function: lib-innerbrowser has some Ajax methods that I don't need if my app doesn't do Ajax; and some Iframe methods; framework modules have Email methods, etc...

I think that the REST module had parts first, probably before I started using Codeception. So this is the original purpose.
Parts functionality was reused to solve module conflicts around 2.2.


Visual studio code intellisense set to javascript lower version

I am using visual studio code 1.20.0
I am not sure when but after some updates vs code intellisense is giving ES6 output in every js file.
I am developing angularjs project & i simply don't want to use es6.
Currently i am getting below code using intellisense.
for (let index = 0; index < array.length; index++) {
    const element = array[index];

}

array.forEach(element => {

});

I want it like it was before. Like below
for (var index = 0; index < array.length; index++) {
}

array.forEach(function(element) {

});

How can i set javascript to lower version. I have not added any plugin in my workspace.
Can anyone tell me how to achieve this.

Duplicate of #37842
We upgraded our small set of built-in snippets to target es6 because this is what most developers are now working in. If you want to write es5 directly, please look in the marketplace for an extension that supplies es5 js snippets or create your own snippets.


fix: array should not add undefined as entry

Codecov Report

Merging #29 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master    #29   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           3      3
  Lines          25     27    +2
  Branches        9     10    +1
=====================================
+ Hits           25     27    +2

Impacted Files
Coverage Δ

src/required.ts
100% <100%> (ø)
:arrow_up:

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 cf6676a...fca7ad8. Read the comment docs.

Coverage remained the same at 100.0% when pulling fca7ad8957b5aedfe4a678e41cd397dce7b201a8 on und into cf6676af61f5b3a51aec7836d97a9ab4a56c0c48 on master.

:tada: This PR is included in version 0.6.3 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


feat: add player name denylist configuration

Closes #111

Sure, we could name it Player Filter & Filter Mode (PERMIT/DENY) - @pajlada @Mm2PL would you also find this preferable?

I'll be the reductionist: How about we only implement an allowlist OR a denylist instead of both?
Simplifies the implementation, simplifies testing, simplifies the config (and how we can explain the config to people) at the cost of making things slightly more difficult for very few hypothetical usecases

I'm cool with just one; which should we choose?
I assume people have more alts than main accounts, so the deny list could be more tedious - but it would save us from bug reports where people complain there is no notification while forgetting to update the allow list (given the list was not empty)

@Newbcake would it be fine for your use case if the feature was implemented as a denylist rather than an allowlist?

@Newbcake would it be fine for your use case if the feature was implemented as a denylist rather than an allowlist?

This would work just fine for my use case.


Feasibility of using custom allele frequency data

Thanks and congratulations on this great tool.
Given that gnomAD predominantly represents certain populations, how could we adapt GeniE to incorporate allele frequencies from our custom dataset, which focuses on an underrepresented population?
Are there considerations for sample size, population structure, or statistical methods? as well as other challenges to consider (dev effort for eg).
Regards

Thank you for your questions, I completely agree that representation is one of the biggest hurdles to accurate genetic prevalence estimates for all diseases. We are already talking about methods of integrating other databases, which take into account things like database overlap (duplicates), relatedness, and methods of variant calling.
One potential option is to allow people to repeat estimates across multiple databases and return separate results. Though this could make interpretation challenging when there are large variances in the results. Another option is the gnomAD team is actively working on federating gnomAD. Federation allows other population databases (many of which are currently underrepresented) to use gnomAD best practices, and then pull in the aggregated AFs from all those databases into gnomAD. This would allow communities to maintain their own population databases, while also improving global AFs, and subsequently GeniE’s estimates.
We are still in the planning phases of these efforts, so I can't provide you with specific requirements at this time (other than federated gnomAD will require using gnomAD's pipeline).  If you are interested in participating please feel free to reply to<EMAIL_ADDRESS>with more details about your database (size, types of data, make up of individuals included) and we can discuss more specifics.


Update Json.NET to 9.0.1

Hi @javiercn, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by .NET Foundation and real humans are currently evaluating your PR.
TTYL, DNFBOT;

:shipit: if it works

:+1:


[Suggestion] Clarify whether Milvus is an end-to-end product in our FAQ

Note: This repository is ONLY used to solve issues related to DOCS.
For other issues, please move to other repositories.

Is there anything that's missing or inappropriate in the docs? Please describe.
Users want to know whether Milvus is an end-to-end product or only works with feature vectors.
Describe your suggestion
Add this info to the FAQ.

Fixed.


Flutter docs point to the wrong Point

The links in http://docs.flutter.io/flutter/dart-ui/Paint-class.html target the Point class from dart:math rather than the dart_ui Point class. Likewise for the Canvas docs and (I would guess) other classes that refer to Point.

Thanks for noticing. I'll open an issue on dartdoc.
cc @devoncarew


SAMZA-2220: Startpoints - Fully encapsulate resolution of starting offsets in OffsetManager

In PR #1026, the startpoint resolution was integrated with only the system consumers, but not the task instances "starting offset caught up logic". Without the correct integration with the task instance caught up logic, the startpoint resolution from PR #1026 is ignored.
This PR encapsulates the startpoint resolution fully in the offset manager so that all components dependent on the starting offsets will get a consistent resolution of the offsets.

@shanthoosh - please take a look when you get a chance.

@dnishimura
Thanks for the patch. Merged to trunk.


Device heating on IOS

react-native-agora: "3.4.7"
Hi guys. Thank you for this awesome package.
We faced with a problem of device heating on ios reported by our clients during long audio and video calls (heating becomes noticeable after 5-10 minutes of call). Only RtcLocalView is displayed on this screen (fullscreen render)
Is it intended to have 50-60% CPU usage on iPhone X during such calls?
Screenshots from XCode Debug navigator attached

Could you point what might be wrong please or is it normal behaviour?
Thanks in advance

Could you pls provide the SDK log?

@LichKing-2234 Thank you for your reply. Here is SDK log:
agorasdk.log


typo fix

"to simulations can be safely restarted" --> "so simulations can be safely restarted"

Purpose

To-do

Content

[ ] I have read and checked the items on the review checklist.

Thank you!


[Firebase Analytics] Flutter Gradle error after installing firebase_analytics: ^5.0.1

After installation of  firebase_analytics: ^5.0.1 I get
FAILURE: Build failed with an exception.
Build file '/Users/<user>/Desktop/odbc/android/app/build.gradle' line: 54

* What went wrong:
A problem occurred evaluating project ':app'.
> path may not be null or empty string. path='null'

add to pubspec.yaml
dependencies:   firebase_analytics: ^5.0.1
add to android/build.gradle
    dependencies {         classpath 'com.android.tools.build:gradle:3.2.1'         classpath 'com.google.gms:google-services:3.2.1'  // Google Services plugin     }
apply plugin: 'com.google.gms.google-services'
add to android/app/build.gradle
apply plugin: 'com.google.gms.google-services'
On trying to debug the application on a virtual pixel 3 I get the error listed above.

I have the same issue. Have you tried to disable Analytics? Or, stepping down the version of cloud firestore?

I have the same issue. Have you tried to disable Analytics? Or, stepping down the version of cloud firestore?

If you mean this version firebase_analytics:  then I have tried 5.0.1 and 4.0.0

Given the age of this issue and that Analytics has had many releases since; I'm going to close this issue in favour of trying the latest release.


Include the application name in update notification

Lessens reliance on recognising the iconography to identify where the notification originated from.

Thanks! ❤


Emit all formats on non-OpenBSD platforms

On non-OpenBSD systems we can't assume OpenBGPD is the most useful format, so we should emit all formats by default this makes life simpler for operators: whatever your goal is running 'sudo rpki-client' will emit a useful format.

To be honest, I would prefer if this change was made in rpki-client itself and not as a -portable patch.
Having the two systems diverge from each other seems like a bad plan.
Also you need to update the manual page.

@cjeker added manpage update. thanks.
I doubt this change is acceptable to openbsd as upstream, since -portable by definition is targetting non-openbsd environments, I think this repository is the right place.

@job, you did not event try. I from my side see no issue of building all formats by default.
The generation is quick and disk space should not be an issue. Just ignore the files you don't need or use one or multiple of the [-Bcjo] flags.

@cjeker ok, will send patch to openbsd

@cjeker I tried :-)
I still think we should embrace the fact that -portable explicitly exists to run on non-OpenBSD platforms, and the easier we make rpki-client to use (just launch the binary) the more adoption and use we'll see down the road.
I understand that carrying this patch around has a cost, but that's what I am here for.

I think this is totally ok for portable. ok benno


CI: add chaos test. (#3056)

Codecov Report
Base: 61.13% // Head: 61.13% // No change to project coverage :thumbsup:

Coverage data is based on head (0a7c02c) compared to base (0a7c02c).
 Consider uploading reports for the commit d8f50b8 to get more accurate results

Additional details and impacted files
@@             Coverage Diff              @@
##           release-1.0    #3128   +/-   ##
============================================
  Coverage        61.13%   61.13%
============================================
  Files              138      138
  Lines            25959    25959
============================================
  Hits             15870    15870
  Misses            8193     8193
  Partials          1896     1896

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Include Videos?

Hey,
i am very new at building websites. This is why i have two questions.
While building my website with this awesome theme, i thought about including a video on my website. So the first question is; is this (easy) possible?
The second question is: Where can i modify the colors that are shown, when the dark theme is applied?
Thanks for all responses :)

Yes you can include video using html5 with the <video> tag which is very straightforward, you can paste it inside your markdown and then it will be rendered.
For the color, you just need to override the _variable.sass, look for the data-theme="dark", there's the theme color and the code highlighting color.


Webpack throws errors only when using plugin

When I run webpack on the command line, it builds successfully with my config. However, when I try to integrate it into broccoli, this is the error I am getting:
Error: Webpack build failures (4):
Module parse failed: /project/node_modules/superagent/package.json Line 2: Unexpected token :
You may need an appropriate loader to handle this file type.
| {
|   "name": "superagent",
|   "version": "0.21.0",
|   "description": "elegant & feature rich browser / node HTTP with a fluent API",

Module not found: Error: Cannot resolve module 'fs' in /project/node_modules/superagent/lib/node
resolve module fs in /project/node_modules/superagent/lib/node

Do you have any suggestions on how to resolve this?

This still happening to you?

So I think this was actually an issue with superagent, but instead of including superagent in webpack I ended up doing superagent/lib/client and I believe that fixed it.


Time format/timestamp-property

Is it possible to have the time in 0-24 format?

I changed the pattern.


retry behaviour

(follow-up from #1016)
At the moment the condition for retrying a request is the following :
func isNetworkError(status int) bool {
	return status == http.StatusBadGateway || status == http.StatusGatewayTimeout
}

Those response status can come either from upstream or be set by the default oxy error handler. To compare this according to proxy_next_upstream semantics, that makes it like :
error timeout http_502 http_504 non_idempotent

Personally I find it too open for a default, if upstream sends http 504 for a POST request it still might have altered a resource but didn't manage to serve the response in a timely manner. For instance with PHP-FPM and nginx I believe this is a common cause for 504 responses, and retrying those POST requests could cause duplicate data or other unexpected side effects.
Should we make this configurable? Or maybe make the pattern more strict? (to compare with nginx again, their default is only error timeout)
cc @emilevauge @SantoDE

Auch! i always assuemed traefik only retries GET. PUT and POST is really dangerous to retry...

HAProxy has a similar default: Only refused connections and timeouts are eligible for retries.
I agree we should adapt a more safe default and consider making this configurable if there's a need for it.

Looking at the definition of 502s and 504s more closely, the error codes are meant to be returned by servers acting as a gateway or proxy. In that sense, non-intermediaries should not emit such error codes AFAICS.
That's not to say we shouldn't change the behavior.

I'm planning to work on this one next.
Which path should we follow? I see three options:

Change the existing logic to only retry on connection errors and connection timeouts (not counting established connections).
Change the existing logic as in 1. but allow to customize the codes on which Traefik should retry (additionally or exclusively).
Keep the existing logic and add an option to (additionally or exclusively) retry on connection errors/timeouts.

Personally, I'm in favor of 1. I'd rather not do 2. until/unless we get some feedback that users actually want a means to customize the codes. Otherwise, we risk maintaining code nobody wants.
I'm against 3. because it was never a safe default in the first place; as such, I consider it "broken design" that we should fix.
Thoughts anyone?
@containous/traefik, what do you say?

@timoreimann I'm also in favor of 1, KISS :)

@timoreimann I have a use case for a web app that is in the process of shutting down to programmatically have Traefik retry the call to another instance. We currently use 502/504 response codes to accomplish this so would be in favor of option 2.

@aschen77 to make sure I understand you correctly: do you that the application is actively producing 502/504 responses and tells Traefik to retry when it's about to shut down?

@timoreimann Yes that is correct. It is a workaround to support graceful shutdown of the application. We use Marathon for application lifecycle and waiting for a better integration with Traefik to remove the app instance from Traefik upon app shutdown.

I think a better option for that case would be to implement graceful termination in Marathon. This requires making your application keep listening for requests on reception of a SIGTERM for a short period while Traefik stops forwarding requests when the TASK_KILLING state is reached. Traefik does not respect the state yet, but it's easy to modify the vanilla template accordingly: This needs an additional if block:
{{$apps := .Applications}}
[backends]{{range .Tasks}}
    {{ if not ( eq .State "TASK_KILLING" ) }}
        [backends."backend{{getBackend . $apps}}".servers."server-{{.ID | replace "." "-"}}"]
        url = "{{getProtocol . $apps}}://{{getBackendServer . $apps}}:{{getPort . $apps}}"
        weight = {{getWeight . $apps}}+  {{ end }}
    {{end}}
 {{end}}

It'd also be easy to upstream this into Traefik.

Thanks for this @timoreimann , this is the proper approach. We will test this and submit a PR to include it in the default Marathon template.

@aschen77 looking forward to it ☺

Closed by #1549


bump to v1.6.0, update ruff restriction

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

@conda-forge-admin, please rerender

@bollwyvl The version tightening applies here as well, although I am not sure about when ruff will declare their API to be stable and change ruff to 1.0.0. But this should be covered by tightening the release to <0.2.0

Stable or no, one advantage of the conda-forge approach is that we can go back in time and fix what the solver thinks... which reminds me, i need to ping on repodata pathces....


Fix #1176 (a bug in the chromadb provider definition example)

Description
This fixes issue #1176 (a bug in the chromadb provider definition, inside notebooks/chromadb.ipynb)
Type of change

[x] Bug fix (non-breaking change which fixes an issue)

Thanks for fixing.


godocs link leads to "Not Found"

Within the README the link https://godoc.org/github.com/hhrutter/pdfcpu leads to a "Not Found" page
Has the page migrated? Thanks!

The package structure changed, may be a caching issue.
I will look into this.

fixed.


CLRerNet for the CurvLane and TuSimple datasets

Thanks your work !! Could you provide the implementation of CLRerNet for the CurvLane and TuSimple datasets, or do you have any related suggestions or code that I can refer to?

Hi, we don't provide the implementation of CLRerNet for Tusimple since the official repo only contains the CULane dataset. However,  the simple implementation of applying CLRerNet to Tusimple is replacing the CLRHead with CLRerHead in CLRNet. We have provided the implementation of CLRNet for Tusimple. Hope this can solve your questions.

Currently, we don't support the CurveLane dataset. Maybe it can be provided in the future.

Thanks for your answer.


Architectural Advice - Global Model?

Hi--
I'm using Cobra command to execute a series of deployments - think something that merges together deploying to GCP, Azure and AWS under a single command.
I am absolutely loving bubble tea - i'm wondering what the right pattern is for maintaining the "model". My initial thought:

In the main cobra command thread, intiialize, and run, the tea program. When it finishes, the application is finished.
Maintain a global singleton of the model - in every sub command/package, etc, provide a function (GetModel()), that gets a pointer to this singleton.
Update that singleton with data as various threads add more information.

Is that standard? Other options - all data update functions are instance functions of the model, or passing around pointers to the model? Am I missing anything?

I don't have all the links / docs / issues etc. when I went down this particular rabbit hole myself but I've settled on "one model to rule them all" including "one view to rule them all" (even on much larger programs, it scales!) and it's just easier to deal with tbh.
This should probably go in https://github.com/charmbracelet/bubbletea/discussions also 😊

thanks! moving over now.


Replacing EC2 Image watcher with CloudAux watcher.

Coverage decreased (-0.2%) to 71.417% when pulling 1334b628803e766e4232ca8c01c2a2300e981ad8 on ec2_image_watcher into 1953ca3375222cafbd00cfded3d3ec581b544d27 on develop.

Coverage decreased (-0.2%) to 71.417% when pulling 1334b628803e766e4232ca8c01c2a2300e981ad8 on ec2_image_watcher into 1953ca3375222cafbd00cfded3d3ec581b544d27 on develop.


Svelte interface to Modal

NativeScript has modals, we probably want to launch a svelte component as a modal

https://docs.nativescript.org/ui/modal-view might be handy to almost always have a root frame

done. it is up to the user to supply a frame


Fix JS regression from 32656

#32656 seem to cause a JavaScript error when visiting https://gitea.com/gitea/helm-chart/pulls/239. process is undefined. Only occurs when logged in.
This should fix it.

And maybe it is fixed by #32661 ? Could you check the version?

And maybe it is fixed by #32661 ? Could you check the version?
Your screenshot shows that the version is "5a50b271e7", which doesn't include #32661

I think this has been resolved by #32661, after upgrading gitea.com. It has been fixed. @justusbunsi
I think this PR could be closed.


Fargate aws_iam_role throwing error due to long cluster_name

Description
When trying to add a Fargate profile to our cluster we are getting an error thrown by the Fargate module. Apparently, the aws_iam_role resource has a char limit on the name_prefix attribute.
⚠ Note
Before you submit an issue, please perform the following first:

Remove the local .terraform directory (! ONLY if state is stored remotely, which hopefully you are following that best practice!): rm -rf .terraform/
Re-initialize the project root to pull down modules: terraform init
Re-attempt your terraform plan or apply and check if the issue still persists

Versions

Terraform:

Terraform v0.13.5

 - Provider(s):
 - Terraform v0.13.5
+ provider registry.terraform.io/hashicorp/aws v3.31.0
+ provider registry.terraform.io/hashicorp/kubernetes v1.13.3
+ provider registry.terraform.io/hashicorp/local v1.4.0
+ provider registry.terraform.io/hashicorp/null v2.1.2
+ provider registry.terraform.io/hashicorp/random v2.3.1
+ provider registry.terraform.io/hashicorp/template v2.2.0

Module: Fargate

Reproduction

Steps to reproduce the behavior:

Clone this repo.
cd examples/fargate/
in main.tf change locals.cluster_name from "test-eks-${random_string.suffix.result}" to "cluster-name-will-have-lot"
terraform init
terraform plan

Code Snippet to Reproduce

Expected behavior

We expect to see a execution plan with the Fargate IAM Role being created using the cluster name.
Actual behavior

Instead, we get the following error:
module.eks.data.aws_ami.eks_worker_windows: Refreshing state...
module.eks.data.aws_partition.current: Refreshing state...
module.eks.data.aws_ami.eks_worker: Refreshing state...
module.eks.data.aws_caller_identity.current: Refreshing state...
module.eks.module.fargate.data.aws_iam_policy_document.eks_fargate_pod_assume_role[0]: Refreshing state...
data.aws_availability_zones.available: Refreshing state...
module.eks.data.aws_iam_policy_document.cluster_assume_role_policy: Refreshing state...
module.eks.data.aws_iam_policy_document.cluster_elb_sl_role_creation[0]: Refreshing state...
module.eks.data.aws_iam_policy_document.workers_assume_role_policy: Refreshing state...

Error: expected length of name_prefix to be in the range (1 - 32), got cluster-name-will-have-lot-fargate

  on ../../modules/fargate/fargate.tf line 3, in resource "aws_iam_role" "eks_fargate_pod":
   3:   name_prefix          = format("%s-fargate", var.cluster_name)

Terminal Output Screenshot(s)

Additional context

I would love to open a PR for fixing this. At first I thought of using the substr(string, offset, length) to limit the cluster name in the fargate.tf file. I tested it and it works for long and short cluster_names. Any other ideas?

I did something similar you have tested the substr(...) with a shorter name?

@stijndehaes yes! In this case the substr(...) returns the original string :smile:

@stijndehaes yes! In this case the substr(...) returns the original string 😄

That sounds perfect :) I have approved your PR. Not that I can merge it but I also need this change :)


Add Jenkinsfile

Trello: https://trello.com/c/kLrX1PqG/580-move-metadata-api-to-new-ci-infrastructure-1
The old CI infrastructure is in the process of being wound down so we
need to move our apps to the new one.

Done in https://github.com/alphagov/metadata-api/pull/32


wireplumber: 0.4.11 -> 0.4.12

Description of changes
Small fixes and nice behavior changes all over: https://gitlab.freedesktop.org/pipewire/wireplumber/-/releases/0.4.12
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Runs fine here, would appreciate some more testing from people with interesting setups though.

Runs fine on my nixos-unstable + cherry-picked pipewire 0.3.58

Never really thought about my setup as "intereseting" though :D Then again I guess running the pipewire graph at 96KHz with two USB soundcards and a bluetooth headset is a bit unusual.


With latest release 3.1.2 Position of pop up calender no longer in correct place

Hi thanks for your nice tool.
It seems that with latest release 3.1.2 the position of pop up calender selector is now in the wrong place.

Last week the calendar selector popped up directly below the flatpickr-input however at some point since it now appears in the top left corner of the page.  I noticed that the a new release 3.1.2 had been made, my application was including it  via
I downloaded the older release 3.0.7 and and wired it up and the calendar behaved correctly again.
Your Environment

flatpickr version used: 3.1.2
Browser name and version: firefox
OS and version: ubuntu gnome

Hello,
Thanks for reporting the issue.
I've traced it down to the new positionElement option.
The issue should be resolved now as of v3.1.3

Confirmed it is behaving correctly again, thanks for the quick response on this one.


Uninstallable under Termux due to node version

OS/Web Information

Web Browser: Chrome 93.0.4577.82
Local OS: Android 11
Remote OS: Android 11
Remote Architecture: aarch64
code-server --version: none

Steps to Reproduce

Install Termux from F-Droid.
Make sure it's up-to-date: apt update && apt upgrade
Install required packages: apt install build-essential python git nodejs yarn
Install code-server: yarn global add code-server

Expected
code-server should be able to install.
Actual
code-server is unable to install since Termux installs node 16.10 insted of 14.X.
Logs
~ $ apt install build-essential python git nodejs yarn
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
build-essential is already the newest version (4.1).
git is already the newest version (2.33.0-1).
python is already the newest version (3.9.7).
The following NEW packages will be installed:
nodejs yarn
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/8865 kB of archives.
After this operation, 53.7 MB of additional disk space will be used.
Do you want to continue? [Y/n]
(Reading database ... 79224 files and directories currently installed.)
Selecting previously unselected package nodejs.
Preparing to unpack .../nodejs_16.10.0_aarch64.deb ...
Unpacking nodejs (16.10.0) ...
Selecting previously unselected package yarn.
Preparing to unpack .../archives/yarn_1.22.10_all.deb ...
Unpacking yarn (1.22.10) ...
Setting up nodejs (16.10.0) ...
Setting up yarn (1.22.10) ...
Processing triggers for man (1.14.5-2) ...
~ $ yarn global add code-server
yarn global v1.22.10
[1/4] Resolving packages...
[2/4] Fetching packages...
error<EMAIL_ADDRESS>The engine "node" is incompatible with this module. Expected version "= 14". Got "16.10.0"
error Found incompatible module.
info Visit https://yarnpkg.com/en/docs/cli/global for documentation about this command.
Notes
This issue can be reproduced in VS Code: No

Thanks for the details! This issue was fixed in https://github.com/cdr/code-server/pull/4230 and will be out in the next release!
Until then, you can either:

downgrade Node to v14 in Termux
use an earlier version of code-server


Reading entire file into memory vs using lock to share file among threads

I recently upgraded to boto3 v1.4.0 from v1.2.3. The new version now uses s3transfer to support uploads, and boto3 Bucket objects now provide a method upload_fileobj for uploading files, which is very nice. The upload_fileobj method delegates to s3transfer. However, it appears that s3transfer reads the entire file into memory when chunking very large files, which has the potential to exhaust RAM. Would it make sense to use a lock to allow multiple threads to access the fileobj instead?
Feel free to reuse the code from that final link. I wrote it and would be happy to have it used here.

Hi @millerdev
So the one reason that we did not go with the locking strategy is that we were concerned it would slow down the speed of the transfer significantly. For most environments, most of the time is spent in reading/uploading the body of the file so if a lock is around the reads we would be making this slow part of the transfer sequential.
So one thing to note with our current approach, while at some point each part of the file will be in the memory, the entirety of file will never be in memory at the same time (assuming the file is very large). To ensure that we do not exhaust RAM from reading the data into we have logic that will ensure a limited amount of file will be in memory for any point in the transfer process.
It is essentially a producer-consumer design where the producers place chunks of the files into a bounded queue and the consumers will pull off of the queue to upload the data and producers cannot place more data onto the queue until the workers make room for them by completing the upload. While there is some memory overhead with this approach, it gives us the ability to do multithreaded uploads with a bounded maximum memory usage. While this is not ideal (ideal would be a minimum memory overhead), it is the best we have so far come up with. The biggest problem is figuring out how to share a file-like object without locking and if we are able to figure that out, that would most likely produce the best performance in terms of both speed and memory. So we are open to suggestions with that.
To be fair, we have not actually tried the locking implementation that you are proposing. Fortunately, we wrote performance scripts to profile the differences between approaches and changes we make to this library. I would actually be quite interested to see what the differences in performance are between your implementation and the one that is currently in s3transfer. So feel free to run the benchmark and benchmark-upload scripts if you are interested in the results as well. Otherwise, we will get to benchmarking your implementation and see if it can improve the library.


feat: get tokens with status False

Close: #1072

Fixed.
Add “include_inactive_tokens” flag as an optional input field to control the return of data with a Status of False.
If you do not add “include_inactive_tokens” flag, API will return data with a Status of True.


Update README.md

Quick install has different instructions than the #48  Lets get the installation working before the quick install.

https://github.com/stitionai/devika/pull/387


Some Issues since latest update of IPython

Environment data

VS Code version:  1.59.0
Jupyter Extension version (available under the Extensions sidebar): v.2021.8.1195043623
Python Extension version (available under the Extensions sidebar): v.2021.8.1105858891
OS (Windows | Mac | Linux distro) and version: WIn 10
Python and/or Anaconda version: 3.8
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): venv
Jupyter server running: Local

Expected behaviour
Previously the following things were working:

When running the IPython environment in VS Code, it would automatically pick the set virtual environment for the folder of the workspace.
When executing lines of code in the IPython console, VS Code would indicate when it was still running code (little not "Executing" and a spinning circle on the bottom left

Actual behaviour

VS Code still states the correct venv on the bottom left, but when starting IPython it just picks the "normal" Python version and one has to manually change it in the top right corner
There is no directly visible indicator if IPython is still busy or already finished executing code. One has to manually expand the cell to see if there is the little green tick underneath

Steps to reproduce:

run IPython for different venv's
run lines of code and try to see when it is done

Thanks for the feedback, @Ov-ille. The second issue you mentioned has been fixed in the latest VS Code insiders build. The picking of the wrong Python is something we need to investigate further. It should be choosing the same environment as is set in the status bar.

@greazer Thank you for looking into this. It's actually causing alot of problems at the moment. Sometimes it takes many, many attempts of restarting the jupyter kernel until the correct venv is actually started. Even when it states the correct venv in the upper right corner, it's sometimes still not using the right one (I can tell when importing a venv specific module)
Also, not all existing venv's appear when clicking on the selected kernel in the top right corner of the interactive window and I just can't get them to work.
Those were never issues before the last update!

@Ov-ille We fixed an issue with the wrong interpreter being picked https://github.com/microsoft/vscode-jupyter/commit/69ae8c3adae683d009d2f81c9ae06c85e6bbc029 We are publishing a new Stable version of the Jupyter extension tomorrow or Thursday which should resolve these issues, and the fix is also available in Insiders. Please let us know if the issue persists in Insiders or the upcoming Stable build. Apologies for the inconvenience.


DSiWare downgrade - Tell the user to install menuhax BEFORE running dgtool expoit.

I had an issue while I was downgrading my 11.0 n3DS using the DSiWare method. After successfuly completing the DSiWare downgrade guide (including installing the exploit through Fieldrunners), I moved on to the 9.2.0 Downgrade part of the guide. When attempting to run the 9.2 downgrade with PlaiSysUpdater, I could never get past "HAX INIT"; as stated in the guide, this may take many attempts, but after a great number of tries, it would still fail.
I was using browserhax to enter the homebrew launcher and run PlaiSysUpdater; I read somewhere that browserhax was very unstable, so I attempted to install menuhax. However, menuhax CANNOT BE INSTALLED on dgtool expoited system. menuhax_manager continuously failed to install. I then attempted to use OoT3DHAX, and running the PlaiSysUpdater downgrade through OoT3DHAX ALSO FAILS. I was at my wits end here :/
Eventually I had realised I could remove the dgtool expoit by restoring from the backup that was made, (F0F1_N3DS.bin) as per the guide. I did this then attempted to install menuhax, and it worked! I then went back to Fieldrunners and reinstalled the expoit. Menuhax still worked after this!
I was able to run PlaiSysUpdater and successfully downgrade!
So, I believe that the guide should tell users to install menuhax BEFORE installing the dgtool expoit, so that they have a reliable homebrew entrypoint for running PlaiSysUpdater.
Cheers :)

I actually installed Menuhax after downgrading the firm TBH, thats weird.

Me too

I used too the dsiware downgrade method but I had not these problems.
Me too,i used Ninjhax to access the hombrew launcher and downgrade to 9.2,and then,i have installed MenuHax naturally after downgrading the firm.

@akirayuki @ederenzi78 @Apollo73 Interesting. it seems that my case was an uncommon one. I think it should still be noted in the guide for the more noobish users, in case they have the same issue I did.

It definitely works. Without any actual logs or errors, I'll be closing this.


feature: removing and renaming redundant definitions

Issue

fix #

Overview

Reference

Screenshot

Before
After

JaCoCo Code Coverage 78.51% :white_check_mark:

Class
Covered
Meta
Status

  Generated by :no_entry_sign: Danger

Snapshot diff report

File name
Image


Task Order not honored

Expected Behavior
Bot honors the task order, for example spin pokestops BEFORE catching pokemon
Actual Behavior
Bot catches pokemon first, no matter what I tell it, resulting in it running out of pokeballs and thus stuck in "wild xyz appeared - no usable pokeballs" loop, till I remove catch tasks from config.
Your config.json (remove your credentials and any other private info)
https://gist.github.com/Dracon23/4b296cefd5ed4f09b282fd68d2b2a50e
Steps to Reproduce

Find a spot rich with pokemon and not in spin range of any pokemon.
Let it sit there, catch pokemon, it WILL run out at some point.
Next pokemon appears, loop.

Other Information
OS: Ubuntu Linux 16.04.1 - headless server
Git Commit: a8242f7bda8cfb1b726173018a903fd4c58f87cc
Python Version: Python 2.7.12 (default, Jul  1 2016, 15:12:24)

@Dracon23 Please post your logs

Fresh right now

Interesting. Your log says you have 99 Ultra Balls available. Should the bot not use these if you have no Pokeballs or Great Balls in your inventory? Seems odd to me. The pokemon catch worker should use whatever the lowest available ball is by default:
            current_ball = ITEM_POKEBALL
            while items_stock[current_ball] == 0 and current_ball < maximum_ball:
                current_ball += 1
            if items_stock[current_ball] == 0:
                self.emit_event('no_pokeballs', formatted='No usable pokeballs found!')
                break

I realise this doesn't answer your question, but there appears to be an issue somewhere related to ball selection.
Maybe if no usable balls, then bot should "run away" to avoid getting stuck in a loop?

@Gobberwart if you’re right and he doesn’t use his ultraball, it’s a known issue and a fix is coming for this. #3421

Potentially related #3563

Yes, I have ultras.... And i,'ve seen the other issue and was pointed to a fix on slack.

What's bugging me (heh)... Is that he won't continue to a poke stop... He just keeps looping the encounter, and doesn.'t do jack till the mon disappears...

OP Issue resolved


Missing products

Hello, you are missing following products:
lobster salad
lemon essential oil
mint essential oil

Ah it looks like we already discussed this in discord so I'll close the issue.
(Just for documentation purposes, the lobster salad was actually called "seafood salad" [which is in the list], and at the time, the essential oils were addable but not yet in the list of autocompletion names due to them being new.  It seems that they are now in the list of names since the HayDay wiki updated the proper pages.)


Hobov2 swagger

Hobov2 swagger change
Switch to "Preview" on this description then select one of the choices below.
Click here to open a PR for a Data Plane API.
Click here to open a PR for a Control Plane (ARM) API.

Hi, @xuexu6666, For review efficiency consideration, when creating a new api version, it is required to place API specs of the base version in the first commit, and push new version updates into successive commits. You can use OpenAPIHub to initialize the PR for adding a new version. For more details refer to the wiki. Or you could onboard API spec pipeline

This PR just bumps up the API version and nothing is changed between version?


indicator issue

if i click on date with event and then click other date, the indicator is not re-apperaing.

Are you talking about event indicator in the sample? There is a line in the code which removes the event on day click:
https://github.com/SundeepK/CompactCalendarView/blob/master/sample/src/main/java/sundeepk/github/com/sample/MainActivity.java#L80

i want it to be removed when that date is selected but i want it to reappear when i click other date

Then delete that line in the sample code. It will no longer remove the event from the calendar.

yes but is there any way to hide the indicator only when it is selected, then on clicking other day it will be visible again?

Sorry I don't quite understand. Lets start from the beginning. What is it exactly you need to do?
There are 3 types of indicators. No. 1 indicator for events (small circle below day in the sample). No. 2 indicator for the current day (dark red in sample) and No. 3 indicator for currently selected day (light red in sample).
Which one of these do you want to show when an event is selected?
The calendar will draw the light red circle when ever you select a day except when you select the current day (No. 2 dark circle) even if there is an event indicator.

im talking about the small one for events (ie No. 1). initailly when the sample code is executed they are shown. but when i click on the date which has event, the small indicator disappears on that particular date and when i click on other date it never appears again on that date. so is there any way to make the small indicator appear on that date again when i choose other date?

i solved it by adding addEvents(compactCalendarView); like this:
@Override
public void onDayClick(Date dateClicked) {
date.setText(dateFormatForMonth.format(dateClicked));
List bookingsFromMap = bookings.get(dateClicked);
mutableBookings.clear();
if(bookingsFromMap != null){
Log.d("MainActivity", bookingsFromMap.toString());
for(Booking booking : bookingsFromMap){
mutableBookings.add(booking.title);
}
}
c
compactCalendarView.removeEvent(new CalendarDayEvent(dateClicked.getTime(), Color.argb(255, 169, 68, 65)), true);
adapter.notifyDataSetChanged();
}
sorry for all the trouble and thanks :)

Are you running the sample code? This seems to be working fine for me as long as you delete/comment out line 80 in the MainActvitiy class.

Yep thats the line which removes events. I'm going to remove that line from the MainAcitivty to get rid of any confusion :).
Thanks.


Enforce Required, Named Parameters

As a developer, when I define a class with a required, named parameter I would like all subclasses to have errors (or at least a warning) if the required parameter was not passed to the superclass.
class A {
  const A(this.x);

  final int x;
}

class B extends A {}

The above snippet currently won't compile (expected):

If I refactor class A to make x a required, named parameter, however, the code compiles just fine without any error/warning (not expected).
import 'package:meta/meta.dart';

class A {
  const A({@required this.x});

  final int x;
}

class B extends A {}

This will definitely not be an issue once NNBD lands in stable but for now it's seems there isn't a good way to safely support required, named parameters.
Additional Info
This tracker is for issues related to:

Analyzer
Dart core libraries ("meta")

Dart Version
Dart VM version: 2.8.4 (stable) (Wed Jun 3 12:26:04 2020 +0200) on "macos_x64"

OS
MacOSX

The analyzer does indeed fail to recognize that the implicit super() of the default constructors (or a user-written generative constructor with an omitted super-call) is not passing a @required parameter.
Compiling should work because Dart compilers mostly ignore metadata like @required. Only the Dart analyzer understand the meaning of @required, but it too fails to give a warning here, (dartanalyzer version 2.9.0-18.0.dev).

This works now with the null-safety feature, required. No further work will be done to support the @required annotation.

This works now with the null-safety feature, required. No further work will be done to support the @required annotation.