ntl: 11.3.2 -> 11.3.4

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/ntl/versions.
meta.description for ntl is: '"A Library for doing Number Theory"'.
meta.homepage for ntl is: '"http://www.shoup.net/ntl/"

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 11.3.4 with grep in /nix/store/mx4jwrnnjlbf3rzp1gwyhmfmbv5zx89s-ntl-11.3.4

directory tree listing: https://gist.github.com/ad52242a9fd3bcf16e88d9df1260423f

du listing: https://gist.github.com/6b5d6fd65333806d75e0c247073536de

Rebuild report (if merged into master) (click to expand)

48 total rebuild path(s)
14 package rebuild(s)
14 x86_64-linux rebuild(s)
11 i686-linux rebuild(s)
11 x86_64-darwin rebuild(s)
12 aarch64-linux rebuild(s)
First fifty rebuilds by attrpath
arb
eclib
flint
giac
giac-with-xcas
ntl
polymake
pynac
python27Packages.symengine
python37Packages.symengine
sage
sageWithDoc
singular
symengine

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/mx4jwrnnjlbf3rzp1gwyhmfmbv5zx89s-ntl-11.3.4 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
Or, build yourself:
nix-build -A ntl https://github.com/r-ryantm/nixpkgs/archive/1421ec2340206c3bcf7500060c9f4c626b73805c.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/mx4jwrnnjlbf3rzp1gwyhmfmbv5zx89s-ntl-11.3.4
ls -la /nix/store/mx4jwrnnjlbf3rzp1gwyhmfmbv5zx89s-ntl-11.3.4/bin

cc @timokau for testing.

@GrahamcOfBorg build sage


Mergeback rc/1.18 to master

Apologies, no internal mergeback PR yet; I'll need to look into that tomorrow.


Use dist forms of quality tool configs consistently

This diff makes use of quality tools a bit more uniform and standardized, and makes minor fixes to a smal lnumber of files so code complies with the php-cs-fixer profile in the repository (tests, however, are still rather far from overall compliance).

Commit 7aae27f treis to correctly handle php extensions -- for require-dev, some are needed to run tests; all the suggestable extensions I was able to find are now suggested. Since an ETL process could be defined for CSV to CSV for instance, none ra actually truly required, I think -- even though some are required for unit tests.

@kdebisschop I merge.
Regarding you last comment
I think if you want PHPdoc type hints, the settings for php_cs_fixer will need to change. If that's the direction people want to take, I'm happy to build another PR for that once there is consensus and the code is in a place where the quality profile can be applied to verify compliance.

Yes ! Let's discuss about this. You can open an issue to centralize all the talks about it :)


iox-#2 Add git hooks

Pre-Review Checklist for the PR Author

[x] Code follows the Rust coding style and is formatted with rustfmt
[x] Branch follows the naming format (iox-123-this-is-a-branch)
[x] Commits messages are according to this guideline

[x] Commit messages have the issue ID (iox-#42 commit text)
[x] Commit author matches Eclipse Contributor Agreement (and ECA is signed)

[x] Update the PR title

Follow the same conventions as for commit messages
Link to the relevant issue

[x] Relevant issues are linked
[x] Add sensible notes for the reviewer
[x] All checks have passed (except task-list-completed)
[x] Assign PR to reviewer

Notes for Reviewer

This PR adds some basic git-hooks

add issue number to the commit message
check for trailing whitespaces
check for style violations with cargo fmt

Checklist for the PR Reviewer

[x] Commits are properly organized and messages are according to the guideline
[x] Code according to our coding style and naming conventions
[x] PR title describes the changes

Post-review Checklist for the PR Author

[x] All open points are addressed and tracked via issues

References

Closes #2

Codecov Report

Merging #72 (d2af8e5) into master (2559c28) will not change coverage.
The diff coverage is n/a.


Make ReactCodeInput a controlled component

Resolves #40.

Replaced componentWillReceiveProps with getDerivedStateFromProps.
Recompute state.input from props.value every time it's updated.

reverted commit after realized that tests are failing, could you please fix them?


MEN-341: Document uboot integration

@michaelatmender: Maybe just check that I got the structure right.


Remove attachements

Add ability to preprocess multiple chat files
Removed all prompts and completions with attachments
Renamed results file
Updated README
Reformat

I accidentally sent a PR to your main branch. Good job on the project!


[RFC] Spatial Filter

Background
We need the functionality to add more than one geometry to allow filtering or drawing on the map.
Problem
Implementing his feature right now is not possible without ejecting it from the Carto4React completely and rebuilding them all from scratch. The current widget FeatureSelectionWidget available in the Carto4React library does not provide this functionality.
Why do we need that
That could be used to share the same implementation across many projects and reduce the time of development for the applications, focussing on providing real value for our customers.
Proposal
The proposed implementation is divided into two different implementations.
FeatureSelectionWidget
The widget must allow the show of various geometries together and if the union between them is inclusive or exclusive.
Spatial Filter
The spatial filter feature must allow saving multiple geometries and show them in FeatureSelectionLayer and MaskLayer
POC

Hi @aaranadev, thx for the proposal.
@bbecquet did a first review and we checked some aspects of it together, to see technical feasibility. We think expanding the Spatial Filter options make sense, at least partially, but we still have some questions to ask, to clarify RFC.
First some technical comments, then questions.
Technical feasibility

State:

the current storage model should be easy to adapt. The mask geometry is GeoJSON. It could be turned into a Multipolygon or a full FeatureCollection if needed
things to add: actions to add/remove/edit by id a specific polygon

deck.gl:

SolidPolygonLayer (used by MaskLayer) should work out-of-the-box with multiple polygons
deck.gl MaskExtension should be able to manage masking by arbitrary number of geometries from the MaskLayer (confirmed with @felixpalmer)

UX/UI

Adaptation of FeatureSelectionWidgetUI to support multiple areas. Potentially the most complex piece.

“The widget must allow the show of various geometries together and if the union between them is inclusive or exclusive.” Here it's where we start having doubts about scope & complexity... see our questions in the next block, and let's call this "multiple polygons mode"

=> is it useful? (Or maybe I’m not understanding this part correctly).
IMO implementing only union (inclusive) is less risky, otherwise with n polygons there are a lot of tricky cases (added to the usual cases about polygons: holes, overlaps, self-crossing ones, etc.).

Questions
1. How core is the "multiple polygons mode" in the proposal? Is it useful to implement only one mode to calculate mask?
2. We would like to have a better definition of 'inclusive' vs 'exclusive' modes. Let's assume user draws 3 polygons, polygon A, polygon B and polygon C. So that means...(please confirm / elaborate more here)
      2.a. INCLUSIVE: The spatial filter would be an OR, and the filter would include the points inside polygon A or polygon B or polygon C
      2.b. EXCLUSIVE: The spatial filter would include points inside polygon A, and not polygon B, nor polygon C... ??
 3. If we understood this correctly, we think that implementing only INCLUSIVE mode feels more clear, and less risky technically, and it would fit in (we would approve that, to go ahead with implementation plan). But it looks like EXCLUSIVE mode would require more elaboration and explanations before moving on, and we're not sure about it

cc/ @moimart

Hi @VictorVelarde , thx for the answer.
With my POC, I've been able to check the technical questions and State and deck.gl are working ok. About UX/UI, I think that is the more complex piece too.
Questions

I think both modes are important.

So that means... you can only use one mode simultaneously in a simple mode.
2.a. INCLUSIVE is an AND, the idea is that you can generate a multipolygon with all the geometries and cross them all.
2.b. EXCLUSIVE is an OR, the idea is that you can generate an array of polygons and source intercept them all separately, generating an array of values.

We need both modes.

If the inclusive/exclusive switch is too complex to add in the UX/UI of FeatureSelectionWidgetUI, we can only allow INCLUSIVE mode on the widget for now, but the exclusive mode has to be in the spatial filter logic.
cc: @efernandezleon

Hi all,
thanks for the proposal, this looks like a great feature. Some thoughts below:
Performance
The more complex the mask gets the slower widgets will run. For points the performance is generally OK, but for lines it is slower and for polygons even slower. As a rough rule of thumb, the runtime will scale linearly with the number of vertices the mask polygon has. This performance hit comes from C4R not deck.gl.
A way to improve this would be to not store circular masks as polygons, but rather as points with a radius. Rendering this with deck is straightforward via a GeoJSONLayer.
Separately, from a UX point of view, it may be worth adding a limit on the mask complexity - or at least a warning.
exclusive/inclusive modes
Regarding exclusive/inclusive: the naming seems unclear to me. Instead I think of it as:

Normal mode: each shape in the mask is equal and any point that is contained in any shape passes the filter
Intersect mode: each shape in the mask is separate, and the final mask polygon is created by the region in which ALL of the shapes overlap

From a deck.gl perspective, the Intersect mode is not supported and the way to implement it would be to compute the overlapping region in C4R prior to passing this off to deck.gl. Agree with @VictorVelarde that this mode is more complex & risky to implement

Ok, now I think I understand better your proposal @aaranadev. I think you want a couple of quite different things…
Let me rephrase those to validate we’re all on the same page:

(a) SINGLE MASK: A way to draw one multipolygon for a single mask. Exactly the same behaviour as current one but with a more complex geometry (I’m considering just one multipolygon, and explicitly excluding here drawing holes). vs

(b) MULTIPLE MASKS: A way to draw several spatial masks, so you have a collection of independent filters, probably also with an associated ID. I think here we all misunderstood it at the beginning and we automatically started to think about “different ways to draw a complex geometry” (but in all cases keeping the idea of a SINGLE spatial filter). This has many consequences, not only in the UI side.

(a) SINGLE MASK. I think that both from [deck.gl](http://deck.gl) & c4r, we see this first piece as a feasible change, not requiring too big changes in the architecture of spatialFilter.
(b) MULTIPLE MASKS. In this case, the impact is potentially quite bigger and we need more info. Let me add some comments / questions:

b1) ui: I think this would require an input in the UI to add proper ID to each filter (or maybe we can safely assume ‘region A’, region B, region C for each polygon…?)
b2) state: we should manage a collection of different / independent spatial filters, with an id + corresponding actions (probably we should assume single-polygon mode for each filter, for simplicity reasons). Probably creating a new set of keys & actions would be better, as overloading current spatialFilter would be complex and probably dirty. This would require several changes in c4r, especially around widgets & also worker calculations.
b3) deck.gl: first we would need to decide how to deal with masks… but probably we would need to manage a collection of different MaskLayer, with custom ID, from the c4r side, so probably no limitations on deck.gl (any limit on the number of masks, due to perf. reasons @felixpalmer ?)
b4) widgets. Main question HERE! ❓❓. Right now the spatialFilter just ‘merges’ with the rest of the filters, without changing dimensions of the feature groups. But if I understand you well, what you suggest here is basically having the possibility of splitting the features into different groups (group A, group B, group C), and that would need to be displayed in the widgets…

Is that correct? Are you expecting that automatic behavior in the context of this RFC? I’m not 100% sure about it. You said you had a PoC, would you share it too?
If that’s the case, this needs more discussion about those effects in widgets… if not please elaborate further...

Perf note: from Felix’s feedback… adding complex geometries would have a clear impact over perf, so yes I also think displaying a warning over XXX vertices would be required (and then we might consider the complexity of using custom structure for Circles in a second step).
cc/ @bbecquet

Great!
I think that the (a): SINGLE MASK, all agree, but I don't understand

and explicitly excluding here drawing holes

Can you explain me?
On another side (b) MULTIPLE MASK
Yes, the impact is bigger because you need to do an intersection by every position of the array.

b1): The name maybe be autogenerated, region A, B, C or Mask A, B, C, is the same to me.
b2): Alright we need to generate a unique id to be able to associate a geometry. About c4r, I've done the changes and they aren't so hard.
b3): The MaskLayer accepts an array of geometries and works very fast, you don't need to change it.
b4): About the widgets... the models aren't changed only the UI

I have a POC but is not accessible because I've copied several parts of c4r and I have done the hack for h3-js  to be allowed to work in workers if you want I can show you the results in a video, or if you want to see the code, I can create a draft with the changes in the repository.

any limit on the number of masks, due to perf. reasons @felixpalmer ?
There can be max four independent masks. Think of each of these as a single color bitmap that contains a rendered deck.gl layer. This layer can be a composite layer, which contains collection of sublayers, so in practice you can render as many layers as you want into a mask. You will have to pay the cost of them being rendered any time the mask changes, which can often be every frame.

Standard (non-mask) layers can specify one (and only one) mask for masking. It is not possible to read two masks and apply the result of both to a layer.

The MaskLayer accepts an array of geometries and works very fast, you don't need to change it.

@aaranadev it would be good to see your PoC, to see how you've implemented the Intersect mode

@felixpalmer @VictorVelarde, I've uploaded the code to public repo.
https://github.com/aaranadev/c4r-compare-mode
You can see the code and test it.
When npm install is done, you need to remove the error of h3-js library, more info: https://github.com/CartoDB/carto-react/blob/master/patches/h3-js%2B3.7.2.patch

@aaranadev this code https://github.com/aaranadev/c4r-compare-mode/blob/main/src/components/layers/MaskLayer.ts#L16 in your example is not doing an intersect. I mean, the SolidPolygonLayer  is receiving a list of polygons so each feature inside the polygons is going to be rendered, right?

Before entering in the technical discussion I'd go a step back and getting more info why do you need this feature. I'm asking because it looks like it's related to comparison mode and I think there are approaches far simpler creating a new widget.

We need the functionality to add more than one geometry to allow filtering or drawing on the map.

Looks like a good feature for CARTO for React. Agree on this

Feature Selection Widget: The widget must allow the show of various geometries together and if the union between them is inclusive or exclusive. The spatial filter feature must allow saving multiple geometries and show them in FeatureSelectionLayer and MaskLayer

Not agree with this approach. There are simpler ways of implementing it. Like creating a new widget that can ask a source to get the data filtered by a custom geom.
I think using the FeatureSelection Widget for this is making it far more complicated
I'll propose a solution early next week

I've setup a meeting next Monday to discuss it and we'll post the conclusion here.
As I see it today. We've proposed this feature because we want to have a comparison mode in site selection. This proposal works but requires a huge effort that it's not required to accomplish the comparison mode in site selection.

The proposed solution is complex and requires lots of non-trivial work. To Give support to multi geometry in the spatial filter, in mask extension, modify the way widgets return data...
It adds complexity for an external user. It's not easy to understand that there is a mode that returns the data per each geometry in the filter.

I think it could be addressed with a simpler approach.

We can modify the workers to return the data based on a custom geometry. So a worker will take the raw data, filter by a custom geometry, and then return the data for the desired widget (formula, histogram, category...).
The comparison mode doesn't need to interact with layers, nor filter other widgets, it just need to show the data, so we can just use the widget ui for that purpose implementing a comparison mode only on the widget ui.


Flow does not recognize static class properties as properties of the class object

Shouldn't the following type-check?  It works fine at runtime.
/* @flow */
function test(props: { prop: number }) {
  console.log('prop', props.prop)
}

const obj = { prop: 1 }

function f(arg: number): void { }
f.prop = 2

class C {
  static prop: number;
}
C.prop = 3

test(obj)
test(f)
test(C)

$ npm install<EMAIL_ADDRESS>$ node_modules/babel/bin/babel-node.js test.js
prop 1
prop 2
prop 3

But flow complains that C doesn't have a property named prop, even though it does if you consider static properties to be properties of the class.
$ flow
test.js:37
 37: test(C)
     ^^^^^^^ function call
 37: test(C)
          ^ class type: C. This type is incompatible with
 31: function test(props: { prop: number }) {
                          ^^^^^^^^^^^^^^^^ object type

Found 1 error

To get flow to accept test(C), I have to change the type of props to be a union of the previous object type and a class object type restricted by an interface:
declare interface I { static prop: number; }
type _ImplementsI<S: I> = Class<S>
type ImplementsI = _ImplementsI<*>

type Props = { prop: number } | ImplementsI

function test(props: Props) {
  console.log('prop', props.prop)
}

That's relying on the fact that interface types in flow are structural per #1179, but it would be more intuitive to let the object type and the interface-implementation-class-object type mean the same thing.

This issue seems like it may be somewhat related: https://github.com/facebook/flow/issues/1190

I think this is supposed to work, but I can confirm that class types can't currently flow into object types. Investigating to see if that was an intentional change...


Need to allow WebNotification for Linux in function 'CheckPermissionOnUIThread'

The function 'XWalkPlatformNotificationService::CheckPermissionOnUIThread' has been involved with patch SHA#3eec718b, in it, we should pass the permission check for WebNotification of Crosswalk for Linux also.

@pozdnyakov @rakuco @halton , please help to review, thank you very much.

lgtm


Add "Develop" Tab to Component Pages

Description
We would like to enhance the component pages by adding a new tab called "Develop" alongside the existing "Overview" and "Guidelines" tabs. The "Develop" tab will host content specifically targeted at developers, offering detailed, component-specific information.
Request

Add a new "Develop" tab to the component pages to provide a dedicated space for developer-focused content.
Automate the display of all props associated with each component within the "Develop" tab.
The props should be automatically generated and integrated into the style guide to always reflect the current state of the components without requiring manual updates.

Expected Outcome
A clear, dedicated space for developer-specific information, enhancing the usability of the style guide for technical users.
Automated presentation of component props in the "Develop" tab, providing quick and valuable insights for developers without manual documentation effort.

Related issue https://github.com/mittwald/flow/issues/799


Loading tileset from atlas

This Issue is about
A problem with my own code
I'm not too sure how to load a tileset image from an atlas. If you load an atlas, it generates a key for the whole atlas, and all the separate parts are frames. However, the API for Tilemap.addTilesetImage does not include a frame option, which makes it so it can't load from there. Is there an easy way to use it, or otherwise it will just be separately loaded?

It could be that's not supported. Probably Phaser assumes the tileset is a complete texture with offsets from (0, 0).
You can try copying the the frame to a BitmapData and using that: https://samme.github.io/phaser-examples-mirror/tilemaps/tileset from bitmapdata.html

Oh, thanks, didn't see that key could also take a BitmapData as input instead of just a string.


Fix solution to work with<PHONE_NUMBER>740992

I added a conversion so it will work with numbers greater than JavaScript's MAX_SAFE_INTEGER:<PHONE_NUMBER>740992

Thanks


Knapsack in C++

Related Issue
Solved issue number: #393
Describe the changes you've made
Adding Source Code for Knapsack in C++
Describe if there is any unusual behaviour of your code(Write NA if there isn't)
NA
Language used for coding
C++
Checklist:

[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] I have documented the code.
[x] New and existing unit tests pass locally with my changes.

Please review the code ;-)


Add ConditionalHelpers support

Hello Wiremock team,
As I told you in issue #1003 I write some code to add by default ConditionalHelpers to ResponseTemplateTransformer. I write also a test and some doc. I hope it helps!

Thanks!


Add accessibility identifier for header

This will be used in acceptance tests to check if the header has changed from messaging to chat in secure conversations. As an added benefit, it can be used whenever checking the header is needed, and it will have the identifier header_ and the title in lowercase appended.
MOB-1752

Is there a way to get an element by accessibility label and not by accessibility identifier? I did it like that because from here it doesn't look like I can use something else. If I recall correctly, the "Configure SDK" button is working like this, where the identifier is changed to have a "_loading" suffix when it is loading, and then it returns to the version without suffix once it is completed. However if there is a better way to do it, I can definitely change it.

Is there a way to get an element by accessibility label and not by accessibility identifier? I did it like that because from here it doesn't look like I can use something else. If I recall correctly, the "Configure SDK" button is working like this, where the identifier is changed to have a "_loading" suffix when it is loading, and then it returns to the version without suffix once it is completed. However if there is a better way to do it, I can definitely change it.

Maybe something like this?
But in case it is not straightforward, I do not insist on finding different solution, so having it as you implemented is also fine.

@igorkravchenko I have followed your suggestion and have just created a generic identifier for the label. Then on acceptance tests, I have created a fixup commit that uses this identifier and checks the label's text.

!merge


fix broken link in .md file

fix broken link in .md file

Thanks, @lukka. Would you mind re-targeting your change to the v15.5 branch since the problem exists there as well? We'll merge v15.5 into master after that to get your fix here too.

retargeting v15.5


Set mods.json version field via CI on release

Currently, mods.json has to be manually bumped for releases. Optimally this should be done via CI when creating a release build. Otherwise the field should say 0.0.0-dev (or 0.0.0 if the former causes an issue with not displaying correctly on clients) when running git revisions directly.

The CI already does that, i update the fields manually to prevent semver errors when checking out a branch and connecting to a public server.


Serenity.Web 3.7.4 Upgrade issue

Hello great guys,
Has anyone encounter issues with the latest update 3.7.4? I have the following errors while trying to Transform T4. This happens either if there is an update to the version or a new project.
**Severity	Code	Description	Project	File	Line	Suppression State
Error		Running transformation: System.IO.FileNotFoundException: Could not load file or assembly 'Serenity.Web, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
File name: 'Serenity.Web, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null'
at Microsoft.VisualStudio.TextTemplatingA12055F8A96EE6C99728F7D5A07E4B36FA7C7634581DADE14C78748E010AC828BA58BD40A8E56151955DCE8264B0E1907AA528712832F191443A4D7F9B1767A8.GeneratedTextTransformation.TransformText()
at System.Dynamic.UpdateDelegates.UpdateAndExecute1[T0,TRet](CallSite site, T0 arg0)
at CallSite.Target(Closure , CallSite , Object )
at Microsoft.VisualStudio.TextTemplating.TransformationRunner.PerformTransformation()
WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].**
Kindly assist.

Reinstall all packages, clear bin directory, update Serenity.Web.Tooling.


Core || Versioning || Develop the routines to automatically version the vector data and metadata during data ingestion (transaction as a resource)

Description
The system shall automatically version the vectored information and the associated metadata whenever a data ingestion pipeline is executed.
Acceptance criteria
Context
Vectored information is used to enable RAG pipelines. The RAG pipeline is sufficiently tested before its is released for production use. Often, addition of vectored information may not result in successful release and the user may need to reset the status of the vectored information to an earlier state. This can be performed in at-least two ways -

Create separate vector stores for new releases and perform data migration or truncate/load the data to reset
Version the vectored information and allow the user to switch the version to an earlier version that is known to work well.
The current vector database platforms implement the first way. This system will implement the second way.
The system will create a new version of the vectored information whenever a data ingestion pipeline is run or if the similarity metric is modified. The system will also maintain a version tree similar to the approach used in source-code versioning systems such as git. The user shall be able to browse through the version tree as and when required.
The system will also version the metadata associated with the vectored information in a similar manner and link it appropriately to the vectored information.

Related issues

https://github.com/cosdata/cosdata/issues/34
https://github.com/cosdata/cosdata/issues/42
https://github.com/cosdata/cosdata/issues/43
https://github.com/cosdata/cosdata/issues/33
https://github.com/cosdata/cosdata/issues/32

Checkpoint 28-Aug-2024
This is work-in-progress. The projection is to complete this by 6-Sep-2024. We expect bugs to exist when the build is complete.


Can't tell when $compile is finished during testing

It's not possible to tell when $compile finishes all of its work, which means that you can't write an async test that leverages $compile. Could either an optional callback be added to $compile, or could a '$compileFinished' event be broadcast on the rootScope?
Below is a contrived example of where it would be useful:
'use strict';

describe('directives', function() {
    beforeEach(module('frShoppingCart.directives'));

    describe('merchant-header', function() {
        it('should include a back link if asked', function (done) {
            inject(function ($compile, $rootScope, $timeout) {
                var element = $compile('<merchant-header back-link="/test"></merchant-header>')($rootScope);
                // The following fails, because $compile isn't done yet
                $(element).children('a').length.should.equal(1);
                $(element).children('a').attr('href').should.equal('/test');

                // It would be nice to be able to do something like:
                $rootScope.$on('$compileFinished', function () {
                    $(element).children('a').length.should.equal(1);
                    $(element).children('a').attr('href').should.equal('/test');
                    done();
                });
            });
        });
    });
});

@lord2800 $rootScope.$digest() right after $compile will be work too.


Getting error when trying to interact in live chat with @docsearch after deploying in web app.

The bot works fine locally with @docsearch , however when running in web app i am getting error
log in web app logstream:
2023-10-30T11:26:48.002567988Z
2023-10-30T11:26:48.002588789Z  [on_turn_error] unhandled error: 1 validation error for AIMessage
2023-10-30T11:26:48.002594489Z content
2023-10-30T11:26:48.002624989Z   none is not an allowed value (type=type_error.none.not_allowed)
2023-10-30T11:26:48.019385627Z Traceback (most recent call last):
2023-10-30T11:26:48.020082732Z   File "/tmp/8dbd938a08a3f74/antenv/lib/python3.10/site-packages/botbuilder/core/bot_adapter.py", line 128, in run_pipeline
2023-10-30T11:26:48.020100033Z     return await self._middleware.receive_activity_with_status(
2023-10-30T11:26:48.020962740Z   File "/tmp/8dbd938a08a3f74/antenv/lib/python3.10/site-packages/botbuilder/core/middleware_set.py", line 69, in receive_activity_with_status
2023-10-30T11:26:48.020980040Z     return await self.receive_activity_internal(context, callback)
2023-10-30T11:26:48.020985140Z   File "/tmp/8dbd938a08a3f74/antenv/lib/python3.10/site-packages/botbuilder/core/middleware_set.py", line 79, in receive_activity_internal
2023-10-30T11:26:48.020989140Z     return await callback(context)
2023-10-30T11:26:48.021769646Z   File "/tmp/8dbd938a08a3f74/antenv/lib/python3.10/site-packages/botbuilder/core/activity_handler.py", line 70, in on_turn
2023-10-30T11:26:48.021803747Z     await self.on_message_activity(turn_context)
2023-10-30T11:26:48.037765778Z   File "/tmp/8dbd938a08a3f74/bot.py", line 110, in on_message_activity
2023-10-30T11:26:48.037786278Z     answer = await loop.run_in_executor(ThreadPoolExecutor(), run_agent, input_text, agent_chain)
2023-10-30T11:26:48.037864979Z   File "/opt/python/3.10.12/lib/python3.10/concurrent/futures/thread.py", line 58, in run
2023-10-30T11:26:48.037873179Z     result = self.fn(*self.args, **self.kwargs)
2023-10-30T11:26:48.037876779Z   File "/tmp/8dbd938a08a3f74/utils.py", line 485, in run_agent
2023-10-30T11:26:48.037880479Z     x=agent_chain.run(input=question)
2023-10-30T11:26:48.037883779Z   File "/tmp/8dbd938a08a3f74/antenv/lib/python3.10/site-packages/langchain/chains/base.py", line 480, in run
2023-10-30T11:26:48.037887379Z     return self(kwargs, callbacks=callbacks, tags=tags, metadata=metadata)[
2023-10-30T11:26:48.037890679Z   File "/tmp/8dbd938a08a3f74/antenv/lib/python3.10/site-packages/langchain/chains/base.py", line 284, in call
2023-10-30T11:26:48.037894179Z     final_outputs: Dict[str, Any] = self.prep_outputs(
2023-10-30T11:26:48.037897479Z   File "/tmp/8dbd938a08a3f74/antenv/lib/python3.10/site-packages/langchain/chains/base.py", line 378, in prep_outputs
2023-10-30T11:26:48.037900879Z     self.memory.save_context(inputs, outputs)
2023-10-30T11:26:48.037904279Z   File "/tmp/8dbd938a08a3f74/antenv/lib/python3.10/site-packages/langchain/memory/chat_memory.py", line 38, in save_context
2023-10-30T11:26:48.037907779Z     self.chat_memory.add_ai_message(output_str)
2023-10-30T11:26:48.037911079Z   File "/tmp/8dbd938a08a3f74/antenv/lib/python3.10/site-packages/langchain/schema/memory.py", line 108, in add_ai_message
2023-10-30T11:26:48.037914579Z     self.add_message(AIMessage(content=message))
2023-10-30T11:26:48.037917879Z   File "/tmp/8dbd938a08a3f74/antenv/lib/python3.10/site-packages/langchain/load/serializable.py", line 74, in init
2023-10-30T11:26:48.037921379Z     super().init(**kwargs)
2023-10-30T11:26:48.037924679Z   File "pydantic/main.py", line 341, in pydantic.main.BaseModel.init
2023-10-30T11:26:48.037936279Z pydantic.error_wrappers.ValidationError: 1 validation error for AIMessage
2023-10-30T11:26:48.037939779Z content
2023-10-30T11:26:48.037942979Z   none is not an allowed value (type=type_error.none.not_allowed)
the live chat works fine with @sqlsearch and @bing , only fails with @docsearch,
however @docsearch works fine locally.

what can be the issue here?

any help?


ENH: Allow setting ch_names

It's nice to be able to remap the ch_names that get plotted. I'm not convinced this is the best API. Maybe instead we should have:
ch_names : str | dict
    Channel names to plot. Can be ``'numeric'`` (default) to use ``['1', '2', ...]``,
    ``'short'`` to use ``info['ch_names'][::2]`` (e.g., ``['S1_D2', 'S2_D1', ...]``),
    or a dict to provide a mapping from ``info['ch_names'][::2]`` (keys) to the
    desired names.

@rob-luke WDYT?

I love it! I can see myself setting src_det_names=None and then using a dict to map S2_D3 = "Planum Temporale" and S5_D2 = "Inferior Frontal Gyrus" etc.
Would this allow new line characters and/or setting S7_D3 = "", i.e. removing channel names for certain channels?

Removing definitely works. Newlines I'll have to check

Newlines I'll have to check

If not, no need to add it here, just make a new issue and we can tackle it later.

Newlines work -- I used src_det_names=defaultdict(lambda: 'a\nb'):

So do you think the API should be as described at the top of the issue, or as it's implemented in the code?

So do you think the API should be as described at the top of the issue, or as it's implemented in the code?

I prefer as described at the top of the issue. I think that ch_names ="short" is much more approachable to a new user than lambdas or dict(zip(str(ii), name.split()[0]) for ii, name in enumerate(raw.ch_names[::2], 1)))

Yes but shouldn't we teach them this beautiful one-liner :)
I'll push a fix tomorrow (EST)

Ready for review/merge from my end @rob-luke

Wonderful, thanks @larsoner


Navbar UI

Description
Make the Navbar UI more appealing.
Currently it is default from an ethreum boilerplate
Type of Contribution
Enhancement, UI/UX
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of this project.

@Suvraneel I can make Navbar UI like this:-

Are there any suggestions on this Navbar UI or should I convert the existing Navbar UI into this? Being a GSSOC'22 participant. Kindly assign me this issue

@shivam123-dev
That's just the opacity & color of the button bro...
You'll need to design something that goes well with background...
Maybe throw in a hover & focus effects as well...
Its pretty straightforward. I built it in a 5day hackathon, so couldnt give much attention to UI... Now there's much room for improvement...


add a link to the API docs to the foxops UI

maybe a link somewhere towards the bottom of the page?

fixed in #47


Routing to child spaces not working

We have configured Dev Spaces for a simple application with an Angular front end and a .NET Core 3.0 webapi. We are able to debug using VisualStudio when running in the parent space, but routing to child spaces is not working. We have added code to propagate the 'azds-route-as' headers and have confirmed that the azds-proxy container is running in all pods. We don't see any 'azds-route-as' headers being added to any calls. What are the best steps to troubleshoot?

Hi @aaronwjha, thanks for reaching out!  Did you add code for propagating the route-as header to the front end or the webapi or both?  Also, can you send us the host suffix for your controller so we can investigate on our side?  You can find it with the azds show-context command.


Add support for custom naming strategies

Fixes #117 and #284.
Question: Were I supposed to work on the 2.7 branch or the master one? If I were, I can send another PR.

Coverage decreased (-2.1%) to 86.164% when pulling 80ef5f247c24341c5124dd28dfbfc5ed3c67d3b4 on gabfssilva:master into e69ae60646c00733f19e38017b7ec6e74644164c on iheartradio:master.

So, I thought I could do the same with SwaggerSpecGenerator, but, since it has lots of apply methods with var args parameters, it was better to leave it as the first parameter.

I tried to merge / cherry-pick this to the play2.7 branch but there are too many conflicts, mainly because of this https://github.com/iheartradio/play-swagger/pull/279 is merged to Play2.7 but not master.
Would you be interested in submitting another PR of this feature to the play2.7 branch?

Sure. I'll do that.


TelnetRCON Keepalive Causes AMP CPU Usage Spike

Bug Report
System Information

Operating System Ubuntu 22.04 LTS
AMP version and build date v<IP_ADDRESS>, built 31/03/2023 20:24
Which AMP release stream you're using Bleeding

I confirm:

[x] that I have searched for an existing bug report for this issue.
[x] that I am using the latest available version of AMP.
[x] that my operating system is up-to-date.

Symptoms

What are you trying to do?
Use TelnetRCON with TeamSpeak 3

What are you expecting to happen?
AMP uses the command for keep alive and the Telnet connection remains stable

What is actually happening? ('Nothing' is not an acceptable answer!)
AMP sends the keep alive and then spikes the CPU to the limit. This is a constant issue that can be reproduced easily.
The last thing the AMP console shows is:
error id=256 msg=command\snot\sfound

2023-04-08 01:58:17.560596|ERROR | | |TS3ANetwork::Bind failed error: 98```

## Reproduction

Create a TeamSpeak 3 instance and set it to TelnetRCON (as I'm about to change the template for now to STDIO). Wait roughly ~10 minutes and view the CPU usage for the AMP service in htop.

What value are you using for RCONHeartbeatMinutes here?

This may be solved as of the RCON redesign.

This was not actually solved as of the redesign. Turned out to be a loop that was reading the line too eagerly from the server. There is now a short delay between each check for data that fixes this.


Tom/field calculation test

Fixes #25
@benmcmillanwarwick I don't think the drift-kinetic routines need modifying, as they work in terms of unit b, so the constant (missing) factor didn't cause any problems, but a second opinion would be appreciated.
I've also added a test which checks the field evaluation routine for uniform and linear fields.

I'm pretty sure some of the drift-kinetic calculations would be wrong without the scaling factor applied, so this probably fixes a bug. I haven't tested all this code carefully yet anyway.
So it is an improvement, and doesn't break any currently-known-working code.


JDG-3135 Add ee.xml subsystem to all WF server configurations

Workaround for WFLY-12472. Can be reverted once we upgrade to WF 18.

Closing this PR, will be fixed by upgrading WildFly .


📖 README: formatting and spelling fixes

Description

Just a few spelling, formatting, and punctuation updates for the README.
Reviewer Checklist

[ ] API Go Documentation
[ ] Tests: Unit Tests (and E2E Tests, if appropriate)
[ ] Comprehensive Commit Messages
[ ] Links to related GitHub Issue(s)

Thanks!


Documentation for the generated classes

Documentation for the generated classes is neatly arranged in some xml files here: https://github.com/godotengine/godot/tree/4f5a7ebaecfcf00cf1e5c4af4b20034f0dcecd29/doc/classes
It should be straightforward and absolutely glorious to write a simple tool that extracts the documentation and adds it to the generated rust code.

Additionally it would be very helpful if functions with optional parameters (in GDScript) had their defaults documented - since Rust does not support default parameters. It would save a step of looking up function in the Godot docs.

My PR #589 gives us this:

where it was all empty before:

Closed in #589.


Dapr state store encryption should switch to AES-CBC

In what area(s)?
/area runtime
TLDR
When following NIST's recommendations, the current implementation of state store encryption in Dapr does not allow encrypting more than 2^33 values without risking compromising the security of the system, even when keys are rotated. We need to fix that by switching to AES-CBC with HMAC-SHA256
Details
Currently, Dapr state store encryption uses AES in GCM mode, with a fixed key (i.e. the same key is used to encrypt all messages), and a randomly-generated nonce.
Per the requirements set by the NIST, in a scenario like ours we should not be encrypting more than 2^32 values with the same key, as the likelihood of a nonce reuse becomes too high after that (a GCM nonce is just 96 bits).
Recommendation from experts we consulted with is to switch to a different cipher, such as AES in CBC mode.

The cipher is AES-CBC with PKCS#7 padding (support for that is being added in dapr/kit already). We are also going to use HMAC-SHA256 for authenticating the message.
To maintain backwards-compatibility, we will include a "version" field in the ciphertext that also indicates the ciphertext, the ID of the key used, and other information such as the IV and authentication tag
This is a good opportunity to also include the name of the key of the key-value (the "row name", not the crypto key) as AAD and fix the issue described in #5998

Alternatives
Using AES-CBC is the only NIST-approved option.
If we want to, we can offer as an alternative ChaCha20-Poly1305 ("ChaPoly"), for example as a config flag (this is being added to dapr/kit too). Although not NIST-approved, it's widely used (it's part of the TLS 1.3 standard) and it can be faster than AES when hardware acceleration is not present (e.g. Raspberry Pi). ChaPoly is a stream cipher so it doesn't require padding. With ChaPoly, a nonce reuse is less risky because it only compromises the security of messages encrypted with the same (key, nonce) pair, while with AES-GCM it compromises the security of all messages encrypted with the same key, regardless of the nonce.
When we include the name of the cipher used in the ciphertext (as described above), we can allow Dapr to decrypt everything even though the config flag sets the format Dapr uses to encrypt data.
Why can't we just have users rotate the keys?
An alternative that doesn't require code changes is to instruct users to rotate their keys at most every 2^32 operations. Although this would address the issue, it's not ideal:

Dapr supports a primary and secondary key to allow key rotation. Only the primary key is used to encrypt data, and the secondary key is only used to decrypt data encrypted with the old key. When the key is rotated, data encrypted with the old key is not automatically re-encrypted. Which means that users can only rotate a key once, so they can only perform 2^33 operations in total with Dapr to be safe (they can manually re-encrypt data with the new key, but that still counts towards the 2^32 limit of operations per key)
Rotating keys requires users to track the number of times a key was used, or at least track how many operations per day are performed to get the approximated number of days.
Rotating keys is a manual operation that is an annoyance and error prone (see for example TLS certificate renewals and how even large companies made mistakes there)

Release Note
RELEASE NOTE: Change Dapr state store encryption to use AES in CBC mode

Proposed implementation 1
Data will be encrypted with AES-CBC (with PKCS#7 padding), with a randomly-generated IV per each message.
The message is serialized in a JSON object that maps to this Go struct:
type EncryptedValue struct {
	// Version of the encryption scheme.
	// This is currently 1.
	Version int `json:"v"`
	// ID of the key, as the SHA-224 hash of the shared key's bytes.
	KeyID string `json:"kid"`
	// Ciphertext (IV is prepended)
	Ciphertext []byte `json:"cpt"`
	// Authentication tag
	Tag []byte `json:"tag"`
}

Version indicates the version of the scheme. This is currently set to 1, but having a version allows us to change the scheme in the future should we need to (e.g. maybe to support other algorithms)
KeyID is the ID of the key. Once Dapr starts, it calculates the SHA-224 of each key, and uses that as ID of the key. This allows mapping each value to the key that is used to encrypt or decrypt it.
Ciphertext is the ciphertext (encrypted message). The IV is prepended to the message.
Tag is the authentication tag - more below.

The authentication tag is computed as the HMAC with SHA-256 of the message. This is performed just like in the JWA standard (RFC 7518 - Section 5.2) and follows the "encrypt-then-MAC" principle.
The authentication tag includes Additional Authenticated Data (AAD) that is the name of the key in the key-value (i.e the "row key" in the database). This allows addressing issues such as #5998

Note: When decrypting data, because we use PKCS#7 for padding, implementations must be careful not to disclose padding errors separately from other errors, so not to allow padding oracle attacks.

Proposed implementation 2
In the proposed implementation 2, data is encrypted using the JSON Web Encryption scheme (RFC 7516).
The JWE is based on envelope/hybrid encryption, where the data is encrypted with a random CEK (Content Encryption Key) that is wrapped with our key. The wrapping key uses the algorithm specified in the "alg" property.

We only support AES-KW as algorithm to encrypt the CEK, so we allow only alg to have values A128KW, A192KW, or A256KW
Data can then be encrypted using AES-GCM (setting enc to A128GCM, A192GCM, or A256GCM). Because the CEK is randomly-generated every time, we can safely use AES in GCM mode without the possibility of nonce reuse in this case.
In the JWE header, kid is set to the ID of the key, computed from the SHA-224 hash of the shared key just like in the proposed implementation 1.
In the JWE specs, the entire JWE header (which is plain-text) is used as AAD when computing the authentication tag. Because we want to tie each value to the key in the state store, we are going to add a custom property to the JWE header that contains the "row key". This too allows addressing #5998.

Lastly, the resulting JWE is serialized in the "compact" format (RFC 7516 - Section 3.1)

Note: we are using only the JWE standard to encrypt our data directly. We are not encoding the data in a JWT first.

Comparison
Proposed implementation 1 (custom scheme)

Pros:

Faster, because there's only 1 encryption step (we do not use envelope encryption)
Encoded data is much more compact because we only include the fields we specifically want. The JWE envelope is more verbose.
Optimized for our needs

Cons:

Uses a custom scheme which is not standards-based
Less flexible. If we want to make changes in the future (e.g. add more supported algorithms), we will need to create a "v2" of the scheme (because we have a "Version" field, this is not hard).
Needs to be written by us, although the amount of effort is not very large given the scope is very small.

Proposed implementation 2 (JWE)

Pros:

Standards-based, so interoperable with external systems
Much more flexible, allowing us to support more algorithms as needed (we don't need this today, but it's likely we will in the future)
Dapr already depends on the github.com/lestrrat-go/jwx/v2 which includes everything we need for using JWE.

Cons:

The encoded data is much larger, because the JWE envelope has a lot of overhead (the header, the CEK, etc). This is especially true for smaller messages, since the overhead is fixed.
The scheme is slower, since we first need to encrypt the data with the CEK, and then wrap the CEK with our key (2-steps).

Upgrade path
We want to make sure that upgrades are seamless and non-destructive. Assuming that this feature lands in Dapr 1.11, our 2 requirements are:

Dapr 1.11 can always decrypt data encrypted by Dapr <= 1.10
We need to be able to support a "mixed" cluster in which some apps are still running on Dapr 1.10

To address these requirements:

When loading a value from the database, we can check the format to determine if it was created by Dapr <= 1.10. Current versions of Dapr store the value as <base-64 encoded ciphertext> || '||' || <key name> (meaning: there's the actual || separator between the ciphertext and the key name). We should be able to detect if this format is being used, then fall-back to supporting the old encryption scheme.
Support for parsing the old encryption scheme will have to be preserved "in perpetuity", as Dapr doesn't automatically re-encrypt old data.
To support "mixed" clusters, Dapr 1.11 will continue to encrypt data using the old scheme. We will add a feature flag that will change Dapr to use the new scheme to encrypt data. The feature flag will be removed in Dapr 1.12, and only the new scheme will be used to encrypt new data.

Other possible improvements
Given that we're making changes to the Dapr state store encryption, we should also consider other improvements:

Allow passing more than 2 keys (primary and secondary). Ideally, we should allow passing an arbitrary number of keys, either as an array in the metadata or as a JWKS file. All keys can be used to decrypt data. A different metadata option can be used to specify which key in the bag is to use to encrypt data; if this key is not specified, the first one in the bag is used. This allows more flexible key rotations, since we're not limited to a primary and secondary key (this is useful because Dapr doesn't re-encrypt old data automatically)
We could look into offering a sample application that will automatically re-encrypt data when the key rotates. This shouldn't be part of Dapr itself, and it could be a sample app.

I vote for the custom envelope since we will not have the overhead of the JWE spec. I would be inclined to use JWE spec if we had any required of interop with other systems. Since this is Dapr specific, I think we should go with our custom envelope.


log the full version name of CDA

this can be collected by dashboarding in order to compare metrics between version changes

This relates to contract W912HQ22F0193 Task 8 Topic B.


Guest driver for win10

Gim driver is installed without any error under centos7.5. When I install gurest driver(19Q1.2) for win10, the screen is in black mode via spice and vnc, also, rdp is in gray blank!
I found the OS is active, but screen is invalidate. Now, I want to program in guest OS, what remote tool can I use ??

usually just use the RDP
by the way ,did you update the kernel in centos7.5?

I have some problems in centos7 with KVM,Hope you can contact me,my email is<EMAIL_ADDRESS>

the same issue as you.


Fix issue #59

Ignore snapCI. Does this work for you then? I don't really use this to anymore

It works for me.
I did not update the .js.min/map files though, since I edited the source file online on GitHub.

Understood. I'll have to pull this down and rebuild/release tomorrow. Thanks!

Released.

9655b4c199e7913a210f1316eadb6ea0d08ddc43 reverted this?

Oh dear... Looks like we just got nailed by this:

I'll fix it up.

Right. Sorry about that.

Alrighty, we should be good now.

Note: I realized that we don't actually need to get setTimeout and clearTimeout from window.self. It doesn't make a difference :-)


Remove the CLI and add a Menu

This menu should also have a area for programmers input, who prefer to use CLI. For example:
wblast --message spam --times 1000 --target name

Can you please describe this issue in little detail.

It wasn't very well designed, you can have your own idea, but the main idea is to remove the CLI and put a menu like the one we have in session_manager

I would like to work on this issue please assign it to me.

@SinghHimadri assigned

@xandao6 Please elaborate this idea here. I'm not understanding what is the main purpose of this idea?

@ rpotter12 instead of having to call "wplay -wb target", we can just call "wplay" and then we will have a menu to choose the option, and we can switch from one option to another.

https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s06.html
Please stick to these rules only.


⚠ SolarOscp has degraded performance

In 3148c46, SolarOscp ($SOLAROSCP_URL) experienced degraded performance:

HTTP code: 200
Response time: 152 ms

Resolved: SolarOscp performance has improved in fcc529a after 12 minutes.


TCP_DEFER_ACCEPT socket option is not supported

Is your feature request related to a problem? Please describe.
When starting apache 2 httpd with LD_PRELOAD=/usr/lib64/mptcpize/libmptcpwrap.so, this error is logged at startup:
[core:warn] [pid 2238878:tid<PHONE_NUMBER>50688] (95)Operation not supported: AH00076: Failed to enable APR_TCP_DEFER_ACCEPT

Describe the solution you'd like
mptcpize should support the TCP_DEFER_ACCEPT socket option.
Describe alternatives you've considered
I've considered ignoring the warning :)
However, there are other applications that will fail if this socket option isn't supported, such as those based on Apache Thrift. For example, MapD fails with:
TServerSocket::listen() setsockopt() TCP_DEFER_ACCEPT Protocol not available

Hi @candrews, this is a kernel issue not a mptcpize problem. I tried to transfer this issue over to https://github.com/multipath-tcp/mptcp_net-next/issues but Github wouldn't allow the cross-organization transfer.
Would you like to resubmit this there to preserve your author information, or should I create a new issue referencing this one?

Created https://github.com/multipath-tcp/mptcp_net-next/issues/271 - thank you!


Use latest version of build_pbf_glyphs

Without this change npm run build failed with the following error:
   Compiling build_pbf_glyphs v1.3.0
error[E0433]: failed to resolve: could not find `generate` in `pbf_font_tools`
   --> /Users/hpg/.cargo/registry/src/index.crates.io-6f17d22bba15001f/build_pbf_glyphs-1.3.0/src/main.rs:136:56
    |
136 |                     if let Ok(stack) = pbf_font_tools::generate::glyph_range_for_face(
    |                                                        ^^^^^^^^ could not find `generate` in `pbf_font_tools`

error[E0433]: failed to resolve: could not find `glyphs` in `pbf_font_tools`
   --> /Users/hpg/.cargo/registry/src/index.crates.io-6f17d22bba15001f/build_pbf_glyphs-1.3.0/src/main.rs:133:50
    |
133 |                 let mut glyphs = pbf_font_tools::glyphs::Glyphs::new();
    |                                                  ^^^^^^ could not find `glyphs` in `pbf_font_tools`
    |
help: consider importing this struct
    |
29  + use pbf_font_tools::Glyphs;
    |
help: if you import `Glyphs`, refer to it directly
    |
133 -                 let mut glyphs = pbf_font_tools::glyphs::Glyphs::new();
133 +                 let mut glyphs = Glyphs::new();
    |

For more information about this error, try `rustc --explain E0433`.
error: could not compile `build_pbf_glyphs` (bin "build_pbf_glyphs") due to 2 previous errors
error: failed to compile `build_pbf_glyphs v1.3.0`, intermediate artifacts can be found at `/var/folders/7s/7z4k6nx13t773txpvsnjpq6c0000gp/T/cargo-installYtiHal`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.
ERROR: "fonts:install_glyph_builder" exited with 101.
ERROR: "fonts" exited with 1.

This is on macOS 14.0, FWTW.

Thanks!

Ah, that makes sense. I'm pretty ignorant about Rust, so just went with the quickest solution I could find. Thanks!


Docker CLI Button does nothing

Well, not nothing. A cursory look in the Dev Tools reveals the following log:
Unhandled rejection Error: /Applications/Kitematic (Beta).app/Contents/Resources/app/resources/terminal DOCKER_HOST=tcp://<IP_ADDRESS>:2376 DOCKER_CERT_PATH=/Users/robin/.docker/machine/machines/dev DOCKER_TLS_VERIFY=1 $SHELL returned non zero exit code. Stderr: 465:465: syntax error: Expected “"” but found end of script. (-2741)

    at /Applications/Kitematic (Beta).app/Contents/Resources/app/build/utils/Util.js:16:18
    at ChildProcess.<anonymous> (/Applications/Kitematic (Beta).app/Contents/Resources/app/node_modules/exec/exec.js:91:5)
    at emitTwo (events.js:87:13)
    at ChildProcess.emit (events.js:169:7)
    at maybeClose (child_process.js:996:16)
    at Socket.<anonymous> (child_process.js:1165:11)
    at emitOne (events.js:77:13)
    at Socket.emit (events.js:166:7)
    at Pipe._onclose (net.js:464:12)

I'm not sure if this is an error with my machine, or some kind of setup error, but I've reinstalled the app, and it still doesn't work.

I guess this is a duplicate of #563, isn't it?

You are correct, sir.


azcosmos occasionally returning 403 Forbidden Connection insufficiently secured

Bug Report

pakage : /sdk/data/azcosmos
SDK version: latest
go version: 1.18.6

Every now and then, a call to cosmos db will return 403 Forbidden, with a message that the client did not use the minimum TLS version:
GET https://XXXXX.documents.azure.com:443/dbs/xxx/colls/xxx/docs/1822b18eb972595bda1b797b332dff1b11567aaaba936ce75824bc0fefdd282e
--------------------------------------------------------------------------------
RESPONSE 403: 403 Forbidden
ERROR CODE: Forbidden
--------------------------------------------------------------------------------
{
"code": "Forbidden",
"message": "Connection is insufficiently secured. Please use Tls SSL protocol or higher\r\nActivityId: adb35793-a4ca-481d-9cc6-dd5d0adf8eb5, documentdb-dotnet-sdk/2.14.0 Host/64-bit MicrosoftWindowsNT/10.0.17763.0"
}
--------------------------------------------------------------------------------
, Dependency: Microsoft.DocumentDB, OriginError: GET https://xxxx.documents.azure.com:443/dbs/xxx/colls/xxxx/docs/1822b18eb972595bda1b797b332dff1b11567aaaba936ce75824bc0fefdd282e
--------------------------------------------------------------------------------
RESPONSE 403: 403 Forbidden
ERROR CODE: Forbidden
--------------------------------------------------------------------------------
{
"code": "Forbidden",
"message": "Connection is insufficiently secured. Please use Tls SSL protocol or higher\r\nActivityId: adb35793-a4ca-481d-9cc6-dd5d0adf8eb5, documentdb-dotnet-sdk/2.14.0 Host/64-bit MicrosoftWindowsNT/10.0.17763.0"
}
--------------------------------------------------------------------------------

Note that the error message includes a reference to the .net document db SDK. We do not use .net, we receive this error when talking to cosmosdb from the golang SDK.
golang 1.18+ defaults to minTLS 1.2 in the http stack, and we explicitely set it anyways.
almost all calls from that same client succeed, and a few calls a day fail with 403 without any changes in configuration. this happens in all regions since early december.

What did you expect or want to happen?

no min TLS error

How can we reproduce it?

run a service that issues calls to a DB continuously, it will hit this error.

Anything we should know about your environment.

I don't think there is anything special about our environment.

Cosmos Go SDK has no custom HTTP configurations and uses the Azure SDK pipeline, I don't see what could be related to this from the Cosmos SDK point of view.
@jhendrixMSFT Is the TLS behavior something that the Go HTTP client sets?

@serbrech You mentioned that this started on early december, was there any change related to the code itself? Was the Cosmos Go SDK updated or changed? Any configuration on the environment that might have changed?
If not code changed, then probably the root cause of this issue is not the application code from what I can understand?

That's correct yes, it uses the standard httop client, which defaults to minTLS 1.2 since go 1.18.
We also happen to manually configure minTLS to 1.2 anyways, it's hardcoded in our client configuration.
I reported this to cosmosdb service directly, and they bounced me to reporting this to the SDK as a client issue, eventhough I can't see how this could happen occasionally, and non-deterministically from the client side...
Note the error message logging a .net SDK, as well as the message itself being poorly worded. it seems it's missing the version argument :

"Please use Tls SSL protocol or higher"
I think the message might be
"Please use Tls SSL protocol 1.2 or higher"
but the 1.2 argument is empty in the gateway code.

the error message logging a .net SDK

This is because the error message comes from a .NET environment, and they are including the internal client identifier, Cosmos DB consumes the SDKs internally too. Your HTTP request is reaching Gateway (https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/sdk-connection-modes) and then internally being routed to the backend replicas through TCP.

I can't see how this could happen occasionally, and non-deterministically from the client side...

My same thought. Unless something on the environment is randomly removing TLS.
So there were no code or environment changes in December and it just started to happen?

Could this be related: https://github.com/Azure/azure-sdk-for-go/issues/19469#issuecomment-1349846202

i'm seeing the same behavior and its not occasional, i'd say its pretty consistent At about 2 out of 10 calls. This is happening both in dev and In production (meaning i highly doubt Its environment On our side).

Could this be related: #19469 (comment)

@ealsur the related issue seems unlikely to me. the call works, just not all the time. i did a loop upserting the same document and out of 100 calls 20 of them threw this error. if it was a config issue i would expect none of them to work.
ps this also just Started recently looking at our logs.

@mattKorwel Is this something that started happening for you too without any client changes? Did you update the Go version by any chance? (that is one of the things we discovered on the other case). When was the date it started for you?

Friday dec 9th is the first time we see it In the logs. no config changes or go version changes i can find. ink fact no deploys that week at all with the early holidays.

We started seeing it early December too. First occurrence in our logs was 3rd if I recall correctly from the investigation data.

@ealsur Any luck on tracing this down? I'm seeing it ever more frequently. I've added retries specifically for this in most code spots but its quite impactful at this point.

@mattKorwel No luck so far, this seems unrelated to SDK, I have reported it to the service team to try and track down the source. So far it seems only Go customers are experiencing it.

I've also started seeing this happen once or twice a day, in code which was deployed last month so it ran without seeing this issue until the 21st Jan.

@ealsur The activity id for one that happened at 00:09 UTC today was ecea9ef6-b5a3-4119-b0d6-b3ec3f1040eb.
The full error was
[*exported.ResponseError]: GET https://xxxx.documents.azure.com:443/dbs/xxx/colls/xxx/docs/xxx -------------------------------------------------------------------------------- RESPONSE 403: 403 Forbidden ERROR CODE: Forbidden -------------------------------------------------------------------------------- {   "code": "Forbidden",   "message": "Connection is insufficiently secured. Please use Tls SSL protocol or higher\r\nActivityId: ecea9ef6-b5a3-4119-b0d6-b3ec3f1040eb, documentdb-dotnet-sdk/2.14.0 Host/64-bit MicrosoftWindowsNT/10.0.17763.0" }

Interesting that the error ^^ says documentdb-dotnet-sdk (i.e. not golang)
@serbrech

@jim-minter
I had the same remark initially. It has been discussed internally, that's the gateway from document db that emits the error adding metadata. I think that's an issue on its own for them, but according to them, it's separate than the root cause.

I came across this thread looking for a solution to the same error taking place in our production environment for approximately the last 2 days. Nothing in our production env has changed. We are using DAPR as part of our microservice architecture which is built in Go, but we're running our services on top of that built in .NET Core 6. The production env has remain unchanged since late 2022, so we know there's no config/code change and we're getting the same error from two of our 26 microservices, and only getting them occasionally, so it seems to be that Cosmos in Azure is rejecting these requests for some reason. Our errors all look very similar to this:
Dapr.DaprException: State operation failed: the Dapr endpoint indicated a failure. See InnerException for details.
 ---> Grpc.Core.RpcException: Status(StatusCode="Internal", Detail="fail to get 2df68788cd9142e6b5b453ff6a8585a9 from state store state-xxx: Forbidden, Connection is insufficiently secured. Please use Tls SSL protocol or higher
ActivityId: e3930f2d-96c9-4ed9-be90-e09098e060b6, documentdb-dotnet-sdk/2.14.0 Host/64-bit MicrosoftWindowsNT/10.0.17763.0")
   at Dapr.Client.DaprClientGrpc.GetStateAsync[TValue](String storeName, String key, Nullable`1 consistencyMode, IReadOnlyDictionary`2 metadata, CancellationToken cancellationToken)
   --- End of inner exception stack trace ---
   at Dapr.Client.DaprClientGrpc.GetStateAsync[TValue](String storeName, String key, Nullable`1 consistencyMode, IReadOnlyDictionary`2 metadata, CancellationToken cancellationToken)
   at xxx.yyy.zzz.GetStateAsync[TValue](String storeName, String key, Nullable`1 consistencyMode, IReadOnlyDictionary`2 meta, CancellationToken cancellationToken)
   at xxx.yyy.zzz.Handlers.GetQuantityAvailabilityHandler.Handle(GetQuantityAvailabilityRequest handlerRequest, CancellationToken cancellationToken) in /home/Technical-Agent/xxx-yyy-deploys/master/xxx-yyy-Services-Availability/xxx.yyy.zzz/Handlers/QuantityAvailabilityHandlers/GetQuantityAvailabilityHandler.cs:line 24
   at MediatR.Pipeline.RequestExceptionProcessorBehavior`2.Handle(TRequest request, CancellationToken cancellationToken, RequestHandlerDelegate`1 next)
   at MediatR.Pipeline.RequestExceptionProcessorBehavior`2.Handle(TRequest request, CancellationToken cancellationToken, RequestHandlerDelegate`1 next)
   at MediatR.Pipeline.RequestExceptionActionProcessorBehavior`2.Handle(TRequest request, CancellationToken cancellationToken, RequestHandlerDelegate`1 next)
   at MediatR.Pipeline.RequestExceptionActionProcessorBehavior`2.Handle(TRequest request, CancellationToken cancellationToken, RequestHandlerDelegate`1 next)
   at MediatR.Pipeline.RequestPostProcessorBehavior`2.Handle(TRequest request, CancellationToken cancellationToken, RequestHandlerDelegate`1 next)
   at MediatR.Pipeline.RequestPreProcessorBehavior`2.Handle(TRequest request, CancellationToken cancellationToken, RequestHandlerDelegate`1 next)
   at xxx.yyy.zzz.Controllers.QuantityController.UpdateRemainingMethod(String id, Int32 remaining, Authentication authentication) in /home/Technical-Agent/xxx-yyy-deploys/master/xxx-yyy-Services-Availability/xxx.yyy.zzz/Controllers/QuantityController.cs:line 318
   at xxx.yyy.zzz.Controllers.QuantityController.SubUpdateRemaining(UpdateQuantityAvailabilityRemainingRequest request) in /home/Technical-Agent/xxx-yyy-deploys/master/xxx-yyy-Services-Availability/xxx.yyy.zzz/Controllers/QuantityController.cs:line 226
   at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.TaskOfIActionResultExecutor.Execute(IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeActionMethodAsync>g__Logged|12_1(ControllerActionInvoker invoker)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeNextActionFilterAsync>g__Awaited|10_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeInnerFilterAsync>g__Awaited|13_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|19_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Logged|17_1(ResourceInvoker invoker)
   at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
   at Dapr.CloudEventsMiddleware.ProcessBodyAsync(HttpContext httpContext, String charSet)
   at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
   at xxx.yyy.zzz`1.LogResponse(HttpContext context, LoggingEntity loggingData)
   at xxx.yyy.zzz`1.LogResponse(HttpContext context, LoggingEntity loggingData)
   at xxx.yyy.zzz`1.Invoke(HttpContext context)
   at xxx.yyy.zzz.Invoke(HttpContext context)
   at Serilog.AspNetCore.RequestLoggingMiddleware.Invoke(HttpContext httpContext)
   at Swashbuckle.AspNetCore.SwaggerUI.SwaggerUIMiddleware.Invoke(HttpContext httpContext)
   at Swashbuckle.AspNetCore.Swagger.SwaggerMiddleware.Invoke(HttpContext httpContext, ISwaggerProvider swaggerProvider)
   at Microsoft.AspNetCore.Builder.Extensions.UsePathBaseMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext](IHttpApplication`1 application)

@RobertGreyling Is this using what SDK? Or is this a custom REST API wrapper on c#?
@jim-minter Yes, this is an internal user agent.

@ealsur - thanks for responding. This was the only place on the internet (so far) I could find even talking about this, but it did seem coincidental that this is being reported in a Go SDK, and our microservice architecture is running on DAPR that's also built using Go. In order to support state calls to Cosmos, I'm assuming it is using that documentdb-go as a library or sorts to interact. Under the covers in there somewhere is something triggering this problem, at least, that's what I'm gathering from all this.
We're currently running on DAPR v1.8 in production and latest is v1.9, so I may look at a simple upgrade to see if that fixes it, but if this is one of the only places talking about this issue, then I imagine not many people even know about it, not giving me much hope that v1.9 will solve the issue. It seems the problem may be resident in a common Go lib that talks to Azure, but I haven't gone digging there yet. That's what I'll likely do if the upgrade doesn't solve it.

@mattKorwel are you able to provide a simplified reproducer?  I haven't yet been able to successfully create one.

I am also working on trying to get a repro, but has been unsuccessful. @serbrech, based on the ActivityId @RobertGreyling is using something that generates this useragent: documentdb-go/v1.3.1-0.20211026005403-13c3593b3c3a dapr-1.5.0 so my guess is this library: https://github.com/a8m/documentdb
I think the only common ground is the Go HttpClient.

@serbrech Yes I can confirm we are using the common state store impl for cosmosdb.
@ealsur I have only supplied one ActivityId, but if you need them, I can supply hundreds more as they are happening quite frequently now, though in relatively low numbers when compared with overall successful traffic.

@RobertGreyling one is enough for now, thanks.

@mattKorwel Could you share your code that repro with upserts?
I wrote a small program that ran all night without triggering it doing upserts and reads... not a single 403
STATS: GET 200 OK:1166188 - POST 200 OK:1166189
yet it happens all the time in prod for us still.
If that helps anyone to work around it, I made the client retry on 403. it's awful and slow, but at least we don't return an error from our API. With this, we haven't seen a single failure in 3 weeks. it has always succeeded on 2nd try.
	opt.Retry = policy.RetryOptions{
		// Create/Update/Delete option will get ItemAlreadyExists error in second retry if first one already arrive server.
		StatusCodes: []int{
			// azcore defaults, see RetryOptions doc
			http.StatusRequestTimeout,      // 408
			http.StatusTooManyRequests,     // 429
			http.StatusInternalServerError, // 500
			http.StatusBadGateway,          // 502
			http.StatusServiceUnavailable,  // 503
			http.StatusGatewayTimeout,      // 504

			// adding 403 to work around random 403 from cosmosdb
			// see https://github.com/Azure/azure-sdk-for-go/issues/19785
			http.StatusForbidden, // 403
		},
		MaxRetries:    2,
		TryTimeout:    5 * time.Second, // The maximum latency in server side in slow EUAP regions are 2-3 seconds today
		RetryDelay:    1 * time.Second,
		MaxRetryDelay: 2 * time.Second, // Delay increases exponentially, delay from 1 second, 2 time will be 2 seconds
	}

Update on this, I have raised an issue via our account manage with the Azure Cosmos product team - still awaiting an update from them as to the cause.
We've also since upgraded dapr to the latest (v1.9.5) on Kubernetes control plane and the dapr client within the docker images running on there. I'm not sure if there is any later version of the Go Azure Cosmos lib being used, but at least everything of ours is on the latest versions.
The problem still persists getting errors a few every hour with thousands of the same calls successful in between - thereby slowly corrupting our data over time. We're using manual data fixes in the mean time, but this isn't tenable over the medium-term.
I'll update when I have more from the Azure product team, but I'm not hopeful it can be rectified with a code fix from the Go side as the default behaviour is to use TLS 1.2 at least which is what the error is saying is not happening.
Any insights I have missed or could try further would be much appreciated.

@RobertGreyling The latest dapr library uses the SDK in this repository, that is experiencing the issue as reported in this thread. The issue seems unrelated to the library being used, but rather related with Go's HttpClient and something on the Cosmos DB Gateway / Service.
I work on the product team, we have been working on trying to reproduce this for the past weeks, and we have not been able to yet find a pattern. The team is still working on it.

Thanks @ealsur - much appreciated. I've got my team putting in a crude "retry" option at the moment as mentioned by @serbrech and looking to deploy that as soon as possible.
This is a really bad problem to have when you're doing Event Sourcing on top of Cosmos and one call out of a thousand fails thereby corrupting the entire event stream from that point onward.
@ealsur - if you require more ActivityIds to investigate payloads from the Cosmos side, I'm happy to provide hundreds of them if you require, and if that helps reproduce the issue somehow. I struggle to see how it's a problem with the Go HttpClient given that the same code is sending the request that succeeds thousands of times and then fails once with effectively the same payload on each request.

@RobertGreyling

I struggle to see how it's a problem with the Go HttpClient given that the same code is sending the request that succeeds thousands of times and then fails once with effectively the same payload on each request.

The only common ground between the SDK in this repo and the SDK where you initially reported the problem (https://github.com/a8m/documentdb) is that they both use Go's HttpClient to send the HTTP requests.
I am not saying there is something wrong on Go's HttpClient, what I am saying is that something on its behavior, under some circumstance (this thread mentions renegotiations, but I am not sure) is conflicting with expectations on the Cosmos DB Gateway endpoint (the one receiving those HTTP requests). What it is, we don't know yet.

Hi @ealsur - yes agreed the HttpClient is the common ground.
It's worth noting that (in my original message) the version of the software we were using had not changed in many months on our deployment side and were getting zero failures of this kind, but that on the 24th January, these error events starting taking place.
In my head, that doesn't point to anything in the behaviour of the HttpClient, under any circumstances, primarily because those same circumstances (behaviour or otherwise) have been happening for months in a stable unchanging environment, and hence I came to the conclusion that something must have changed downstream from there.
We don't have access to how Cosmos or the Gateway change over time as that is internal to your team of course, but perhaps looking at what might have changed around those dates could point in the right direction?
I would imagine looking at the Cosmos gateway that comparing a successful ActivityId versus an unsuccessful ActivityId of exactly the same payload may help in determining where the problem lies. Such data will become available once this retry option is in place, but my guess is that your team may already have access to that sort of data.
I would also think that additional telemetry is being recorded relating to these failed requests attached to the ActivityIds where headers and protocols can be inspected to determine if the request truly was being made with something less than TLS 1.2, or if in fact the gateway rejected it regardless of its TLS level?
These are questions I cannot get answers to, but being on the inside, you may have better mileage.

For the sake of completeness, we have this morning deployed a new version of our microservice that has a retry option for 403 responses specifically from state failures (gets, puts or posts) linked to this Go HttpClient.
We have since had two failed GETs (ActivityId: 918c25fa-cb80-413a-8d57-52358bbfe31b and f776b2d2-3b96-473b-b69e-b4db4f6a3641) within a few minutes of each other. The subsequent retries of both which happened milliseconds after each request, succeeded without any issue, and as such, we have avoided the subsequent data corruption for these calls.
Of course as has been mentioned on this thread before, this is not ideal, but at least it seems we are not suffering the consequences now - I will update if that changes.
@ealsur I hope those failed ActivityIds can be of some assistance to the internal team, given that an identical request directly afterward succeeded which should hopefully allow the team some guidance on reproducing the issue.

In my head, that doesn't point to anything in the behaviour of the HttpClient, under any circumstances, primarily because those same circumstances (behaviour or otherwise) have been happening for months in a stable unchanging environment, and hence I came to the conclusion that something must have changed downstream from there.

There was definitely something that changed on the service side, some new validation over TLS that was not there before. Go is the only language reporting these failures related to TLS after this validation seems to have been added, my guess is there is something different that only happens on Go regarding TLS that does not replicate in other languages (.NET, Java, NodeJS, Python have Cosmos SDKs and not reporting this problem). Probably this behavior was always there but the validation now brought it up.

@ealsur that makes sense, and if you've confirmed tighter validation constraints put live in Cosmos/Gateway over the last few weeks, then that make sense too and it all lines up.
In that case, there may be a potential fix that could find its way into the Go HttpClient once the root cause is found. I'm not sure this SDK is the correct project to be reflecting on that then, and instead perhaps an issue needs to be raised on https://github.com/a8m/documentdb if that is indeed the root library for this issue? I haven't been able to confirm that it is, or at least which version, but I note that others have mentioned it, including yourself.
The dapr team would also be interested in knowing about this as anyone using Cosmos via dapr state management are not getting a reliable experience and possibly don't know about it yet.

@RobertGreyling This repository is for the azcosmos library (official Cosmos DB Go SDK) which is user in the latest version of dapr. I believe the dapr team is already aware of this.

Update from the Azure Cosmos issue raised via support - they tell me that some configuration changes have been made on the Cosmos/Gateway side and continuing to monitor for 403 errors. I suspect you may have further insight on this @ealsur but mentioning just in case you're not on the internal chain of comms.
From our Production service logs, I'm happy to report that we've had no further "retries for 403 errors" attempted for the last 12 hours now which means we're no longer experiencing the issue retries were put in place for. We'll be monitoring through the day, but given that we've consistently had at least 3 or 4 per hour over the last two weeks, to have had zero in 12 hours sounds like tremendous progress.
Fingers crossed it stays that way - though I would be interested to know what the config change may have entailed.

Can we have an RCA here, or will that be internal only?

What is the fix deployment schedule?
I have not seen any changes from our logs point of view. We still get occasionally the same TLS failure.

That's strange @serbrech - FYI we've not had a single TLS error in production since Feb 8
I was under the impression the fix was service-wide, but perhaps it's only been applied to our instance?
I'm still waiting for the RCA from my account manager/support ticket

@serbrech I have no visibility on support engagements, I am not aware of any service-wide fixes regarding this issue. But my area of engagement is client SDKs, I don't know what changes could have been made/are planned on the service side, so I cannot comment, I don't know what change was done.

I went and reached out to the team to get more clarity and details about the situation to share here. The team has identified a fix related to HTTP2 protocol, and it's in the final stages of testing. Once that is completed, it will rollout to all Gateway endpoints but there is no fixed date for this yet as testing is underway (and we know based on the experience on this thread how hard it might be to test/replicate). Will share more updates as it progresses.

This issue has been fixed on the service and the fix has been widely deployed. Please re-open if the issue is still happening or arises again.


Update CODEOWNERS and MAINTAINERS.md initially

Problem description

CODEOWNERS and MAINTAINERS.md are not yet set.
Expected action

Needed data collected within https://github.com/camaraproject/APIBacklog/issues/60
Both files updated
Additional context

Done within #4


Releasing deque v1.0.2

Releasing Roger's amazing changes to deque! Absolutely incredible job, @rogpeppe ! 👍

Codecov Report

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

@@          Coverage Diff          @@
##           master    #12   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           1      1
  Lines         126    126
=====================================
  Hits          126    126

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 6a4b2cb...2de0a6c. Read the comment docs.


Drop MinGW builds

I read about building python extensions with MinGW and there seems to be lots of problems with it. I'm surprised that we didn't have any problems till now. See https://mingwpy.github.io/issues.html#ms-gcc-abi-incompatibilities for more info. One thing we can do is try mingwpy. Till then I suggest dropping these tests. This seems to be a problem with 32 bit MinGW and MinGW-w64 64 bit builds still work.

I'm going to merge this as @certik mentioned +1 via chat.

Yes, this is +1.


[apps] fix for potential but unlikely race condition

to: @javuto
cc: @airbnb/streamalert-maintainers
size: small
resolves N/A
Background
Identified a very unlikely but possible race condition that could occur. In short, a 'chained' invocation of a app function could be started before the config in Parameter Store was properly updated with the partial state value. This could then cause the new invocation of the lambda to fail if it read the state as running before it was written to partial
Changes

Writing the partial state config to parameter store before invoking the new lambda function.

Testing

Unit tests passing.

Coverage decreased (-0.002%) to 95.586% when pulling de89c3e0d640c584ccfe3da31aa862c0922b2d29 on ryandeivert-app-check-order-change into a9e7d3c2724a86970576bde3db3e7f2e64ec22bc on master.

FYI the coverage drop is due to the total number of lines decreasing by 1 🤣


Upgrade dart to 2.19.3

This is a mistake, 2.19.3 was already pushed to dart-docker automatically.


Avoid error in windows due to temp file being locked

In the process to use hie-bios on ghc i hit a problem when the hie-bios script tried to write in %HIE_BIOS_OUTPUT$: the file was locked by the executable and the script could not write in it

As usual in posis systems the lock works in a way the process started by hie-bios can write

Now the file es created but it is not opened until the process has used it. It is not deleted auto when it finishes but i thin kit is no a big problem, being a temporal file (but i could add a deleting)
I've changed the handling of %HIE_BIOS_OUTPUT$` to honour the possible previous value set by the user: maybe it can be used if users pnly have permissions over concrete directories or they want to keep the compiler args in a file controled by them

This will leak bios-output files into TMP. You need to clean up the temporary file after the cradle has finished running.

@mpickering done! it is clearner now

@mpickering @fendor i think it is done, thanks for the review and suggestions.
I tested the last version in my win 10 with the ghc config and it works: it uses the file pointed by HIE_BIOS_OUTPUT and a temp file (like before) if it is not

Thanks LGTM. Over to you @fendor

Thanks!, only a correction to my previous comments for the shake of being precise:  with the change from withSystemTempDirectory to withSystemFileDirectory the behaviour is the same as before the pr and the file is always created.
So the check for the existence of the file had no sense anymore (again like before the pr) and it is well removed.
However, the file can be empty and it would no trigger any error. I've checked it sending the output of hadrian/hie-bios.bat to nul and running hie-bios check ghc\Main.hs to see the temp file was created but compiler options are empty.
That is the reason that stack path call is succesful although it does not write anything to $HIE_BIOS_OUTPUT.


[ja] Update docs/concepts/workloads/controllers/daemonset.md to follow v1.19 of the original text

[ja] Update docs/concepts/workloads/controllers/daemonset.md 1.18 to 1.19
Resolve #26897

/lgtm

/approve


Provide the ability to auto enable BPF LSM in nodes through operator

Feature Request
Description
KubeArmor supports both AppArmor and BPF LSM as enforcers. However, there is a difference between the feature set. If it is possible, we ask users to enable BPF LSM for a better experience.
However, to enable BPF LSM certain steps as listed here must be followed. We provide a script that users can use to enable BPF LSM on their node however it has it's own caveats.
Thus, we need to provide the ability to enable BPF LSM on compatible nodes through the operator.
Describe the solution you'd like
KubeArmorConfig CR has an updateLSM field. When set to true, based on the annotations applied by snitch, it would either enable BPF LSM itself or through the above mentioned script. Points to keep in mind:

Reboot of nodes

Operators generally follow this mechanism of updating/restarting a node based on annotations set by the user. For example, the nvidia operator has a flag to determine whether a node should be upgraded or not.
Make sure that this happens in a rolling update manner.

Show users the status of nodes.

karmor probe is an option but it requires users to download the tool.
If possible, show this using KubeArmorConfig CR status field.

So the flow would be like this @DelusionalOptimist ?
1: Extending KubeArmorConfig CR Specification
Modifying the spec section of the KubeArmorConfig CR to include an updateLSM field. This field will indicate whether the operator should attempt to enable BPF LSM on the node.

apiVersion: operator.kubearmor.com/v1
kind: KubeArmorConfig
metadata:
  labels:
    app.kubernetes.io/name: kubearmorconfig
    app.kubernetes.io/instance: kubearmorconfig-sample
    app.kubernetes.io/part-of: kubearmoroperator
    app.kubernetes.io/managed-by: kustomize
    app.kubernetes.io/created-by: kubearmoroperator
  name: kubearmorconfig-sample
spec:
  updateLSM: false

2: Implementing a function within the KubeArmor operator to check if the current kernel version supports BPF LSM
func isKernelBPFCompatible(kernelVersion string) bool {

    var supportedVersions = []string{"5.8", "5.9", "5.10"...and so on}
    for _, v := range supportedVersions {
        if kernelVersion == v || kernelVersion == "v"+v {
            return true
        }
    }
    return false
}

3: after that we apply Annotations based on compatibility...If the kernel version is compatible
if isKernelBPFCompatible(kernelVersion) && config.Spec.UpdateLSM {
    nodeClient.SetAnnotations(nodeName, map[string]string{
        "kubearmor.enable-bpf-lsm": "true",
    })
}

4: Ensuring the operator handles node reboots gracefully
nodeClient.MarkNodeForReboot(nodeName)
waitForNodeReady(nodeName)

5: Updating KubeArmorConfig CR Status based on actual status
status:
  bpfLsmEnabled: false