PQ KEMs behind a feature flag

Implements 2 PQ replacements of DH-KEM

ML-KEM -- https://csrc.nist.gov/pubs/fips/203/final
XWing -- built by combining ML-KEM with DH-KEM using a generic combiner -- https://datatracker.ietf.org/doc/draft-connolly-cfrg-xwing-kem/

Call outs
DH-related functions were only copied
Safety
I did run mls-rs-crypto-aws-lc tests with address sanitizer and stared at the code very long. Unfortunately aws-lc-rs does not currently support

SHAKE
storing a decapsulation key as bytes
deterministic key generation which is experimental in AWS-LC

Testing
I would love to run some tests from the XWing RFC but unfortunately they seem to be incompatible with ML-KEM from AWS-LC and they don't contain intermediate values I could use to only test the combiner. We could generate test vectors based on the XWing implementation in the future.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT license.

Codecov Report
Attention: Patch coverage is 48.60140% with 294 lines in your changes missing coverage. Please review.

Project coverage is 89.45%. Comparing base (474dc47) to head (1b60655).
Report is 1 commits behind head on main.

Files with missing lines
Patch %
Lines

mls-rs-crypto-hpke/src/kem_combiner.rs
0.00%
216 Missing :warning:

mls-rs-crypto-awslc/src/lib.rs
74.35%
40 Missing :warning:

mls-rs-crypto-awslc/src/kem/ecdh.rs
84.95%
17 Missing :warning:

mls-rs-crypto-hpke/src/dhkem.rs
69.69%
10 Missing :warning:

mls-rs-crypto-traits/src/kem.rs
0.00%
4 Missing :warning:

mls-rs-crypto-openssl/src/ecdh.rs
40.00%
3 Missing :warning:

mls-rs-crypto-rustcrypto/src/ecdh.rs
40.00%
3 Missing :warning:

mls-rs-crypto-awslc/src/kdf.rs
92.85%
1 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #221      +/-   ##
==========================================
- Coverage   90.17%   89.45%   -0.73%
==========================================
  Files         176      178       +2
  Lines       31558    31915     +357
==========================================
+ Hits        28458    28548      +90
- Misses       3100     3367     +267

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


can't update to 1.0.3 using bower

bower.json
"dependencies": {
  ..
  "angular-nl2br": "1.0.3",
  ..
}

$ bower update
...
bower angular-nl2br#1.0.3            ENORESTARGET No tag found that was able to satisfy 1.0.3

1.0.2 works but it doesn't have the input check fix from PR #2 :cry:

Should be fixed now. Thanks!


REST API bug when starting an container

Output of docker version:
Client:
 Version:      1.12.0
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   8eab29e
 Built:        Thu Jul 28 21:40:59 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.0
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   8eab29e
 Built:        Thu Jul 28 21:40:59 2016
 OS/Arch:      linux/amd64

Output of docker info:
Containers: 291
 Running: 9
 Paused: 0
 Stopped: 282
Images: 62
Server Version: 1.12.0
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 688
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options:
Kernel Version: 3.16.0-4-amd64
Operating System: Debian GNU/Linux 8 (jessie)
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 15.41 GiB
Name: tyr
ID: BOKP:BDNT:4NX7:D26W:3M7L:Y2TV:RSMA:EYGV:C2CS:REFP:EVNH:3EPY
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 56
 Goroutines: 77
 System Time: 2016-08-12T17:32:13.892406816+02:00
 EventsListeners: 1
Registry: https://index.docker.io/v1/
WARNING: No memory limit support
WARNING: No swap limit support
WARNING: No kernel memory limit support
WARNING: No oom kill disable support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support
Insecure Registries:
 <IP_ADDRESS>/8

Additional environment details (AWS, VirtualBox, physical, etc.):
Steps to reproduce the issue:

Create a container but do not start it yet
Try to start it via the REST API
Will fail with starting container with HostConfig was deprecated since v1.10 and removed in v1.12

Describe the results you received:
The container did not start and I am recieving an 400 HTTP Code instead.
Debug Logs from dockerd:
Describe the results you expected:
Starting the container should just work fine if the post payload is empty or an empty json, e.g. {}
Additional information you deem important (e.g. issue happens only occasionally):

Aug 12 17:29:21 tyr dockerd[9899]: time="2016-08-12T17:29:21.278363023+02:00" level=debug msg="Calling POST /v1.24/containers/2e5b53aef3845502580e9ee8acdcd57f967d761015210c05dc37a208438e8250/start"
Aug 12 17:29:21 tyr dockerd[9899]: time="2016-08-12T17:29:21.278425649+02:00" level=debug msg="form data: {}"
Aug 12 17:29:21 tyr dockerd[9899]: time="2016-08-12T17:29:21.278449660+02:00" level=error msg="Handler for POST /v1.24/containers/2e5b53aef3845502580e9ee8acdcd57f967d761015210c05dc37a208438e8250/st$rt returned error: starting container with HostConfig was deprecated since v1.10 and removed in v1.12"

There are also cases where everything just works fine:

Aug 12 17:37:14 tyr dockerd[9899]: time="2016-08-12T17:37:14.769505957+02:00" level=debug msg="Calling POST /v1.24/containers/0af742407d8631299b5e37da4cfc10374d26294e6b4b5c7dce89eff1e8ec581a/start"
Aug 12 17:37:14 tyr dockerd[9899]: time="2016-08-12T17:37:14.769582892+02:00" level=debug msg="form data: {}"
Aug 12 17:37:14 tyr dockerd[9899]: time="2016-08-12T17:37:14.770618666+02:00" level=debug msg="container mounted via layerStore: /var/lib/docker/aufs/mnt/f01da2f0f153a1a0f80b4e28fabd86dd23b3af3d694c9af92aee133793b0ba5e"

Is there a way to log eveything that comes in via the API user headers etc? Because I can't see a difference between those two POST requests

What software are you using to work with the API? Older versions of docker accepted a HostConfig JSON at /containers/<container>/start that allowed changing the hostconfig that was set during "create". This is no longer supported (that's what the message says).
I suspect the tool you're using is trying to set HostConfig, but that fails (as expected)

I am using https://github.com/docker-java/docker-java
But isn't it weird?
Works:

Aug 12 17:37:14 tyr dockerd[9899]: time="2016-08-12T17:37:14.769582892+02:00" level=debug msg="form data: {}"
Does not work:
Aug 12 17:29:21 tyr dockerd[9899]: time="2016-08-12T17:29:21.278425649+02:00" level=debug msg="form data: {}"

I can't see a difference in the Output, so I am suspecting a bug here..

ping @KostyaSha perhaps you know?

Will fail with starting container with HostConfig was deprecated since v1.10 and removed in v1.12

That not a docker issue and not a docker-java bug. It just docker-java doesn't support 1.24 API version.
docker-java allows set api version, set it to 1.23 until we update models.

@KostyaSha It is correct that docker-java does not support 1.24 yet, see https://github.com/docker-java/docker-java/issues/617
However I still can't see a difference in those 2 log messages above.
I don't know why docker-java fails here, since it is sending an empty JSON object which seems correct.

see issue about sending or not sending empty requests. Btw docker team please comment something what is right and doesn't
Sent from my iPad

On Aug 12, 2016, at 7:58 PM, P<EMAIL_ADDRESS>wrote:
@KostyaSha It is correct that docker-java does not support 1.24 yet, see docker-java/docker-java#617
However I still can't see a difference in those 2 log messages above.
I don't know why docker-java fails here, since it is sending an empty JSON object which seems correct.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@KostyaSha where is this issue? Or did I miss something?

When client sends empty {} json to docker daemon, daemon think that it old format with HostConfig error message. Possible solutions:

fix error message
allow empty json
In docker-java only jersey impl was affected.

@KostyaSha API version 1.24 and above will produce an error if a JSON object is sent (including an empty object); older versions still accept the JSON object for backward compatibility.
see api/server/router/container/container_routes.go#L137-L152, and /daemon/start.go#L39-L63

Sorry, 7 chars is magic value? Please change message to "Doesn't accept any JSON body" to be clear;

#25778


Please add Server-Send-Events on changes to the json data

Would be nice if the json-server would offer server-send-events when data gets created, modified or deleted.
Front-ends then could use EventSource to get notified and can react on the changes.

@Alex-Jongman I had a use for this and created a PR for this here

@ikeohachidi thanks for the info. I tried you PR, unfortunately it didn't fulfill my needs.
But it gave me inspiration to create a fork myself (see here).
Hope that the SSE feature to prevent clients from have to use active polling, to determine changes in the data will make it to the main branch.


Evaluate test cases and sketches independently

Currently, if trials.xml refers to a sketch it looks like floodgage marks a synthesized program as PASS only if both the test cases and the sketch pass evaluation. It would be useful to separate these two in the output, for example: [PASS] Test cases [FAIL] sketch.

Looking at the output it can get confusing. I'm playing around with it now.  Question: what exactly do we want to say constitutes a trial pass?  Would it be "for this trail (draft) there exists a result that both passes all test cases and conforms to the sketch?"  We treating each result now as a sort of individual unit.  I'm not sure that is the most valuable reporting.

I would say the check should be at least one, because we only synthesize unique sketches from the model for each query. However, while we're still figuring this out and tuning the system, it would be useful to have the full output. Also, make sure to implement it such that one can "configure" a floodgage run from the command line/config file (e.g., number of samples from the AST server, number of output programs, etc.).

The output looks better now, but I think the build process can be improved. First let's strictly not have any jar files in the repo please, unless they cannot be obtained from source (like android.jar). Latest commit on issue-129 updates an 18MB floodgage jar, for which git is going to track history on each and every update. I would highly suggest integrating the build process for floodgage into the repo.
Secondly, I also feel uneasy about having the trials.jar for each trial. If a trial is to be updated, one has to copy the contents to the trialpack repo, build it there and copy back (not to mention commit the .jar file -- see above). Can we move those files, or at least the build.sh script from trialpack, here? That way we don't need to have jar files floating around for trials, which can also be built from source.

If you prefer to track this in a separate issue and mark #129 solved, go ahead and start a pull request.

Updated output to show score categories over total score.  If looks good let me know and i'll issue a pull request.

Merged #131.


move missing endpoints log to buildCluster

Please provide a description of this PR:
To help us figure out who should review this PR, please put an X in all the areas that this PR affects.

[ ] Ambient
[ ] Configuration Infrastructure
[ ] Docs
[ ] Dual Stack
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure

Please check any characteristics that apply to this pull request.

[x] Does not have any user-facing changes. This may include CLI changes, API changes, behavior changes, performance improvements, etc.

@hzxuzhonghu: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
754b514363f0f0ef67f1ff02fb7d0a6bb7aea752
link
true
/test release-notes

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
754b514363f0f0ef67f1ff02fb7d0a6bb7aea752
link
true
/test release-notes

integ-pilot-multicluster_istio
754b514363f0f0ef67f1ff02fb7d0a6bb7aea752
link
true
/test integ-pilot-multicluster

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-pilot-multicluster_istio
754b514363f0f0ef67f1ff02fb7d0a6bb7aea752
link
true
/test integ-pilot-multicluster

release-notes_istio
8872d23d0a2016adbbca9752d0bb0730712e4082
link
true
/test release-notes

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-pilot-multicluster_istio
754b514363f0f0ef67f1ff02fb7d0a6bb7aea752
link
true
/test integ-pilot-multicluster

release-notes_istio
8872d23d0a2016adbbca9752d0bb0730712e4082
link
true
/test release-notes

integ-ambient_istio
8872d23d0a2016adbbca9752d0bb0730712e4082
link
true
/test integ-ambient

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest


Implement timeout and ontimeout on XMLHttpRequest

Closes #4648

I like that this is a pure-JS solution (because it works x-platform), but there is already a timeout set on the native side (60s by default on iOS: https://developer.apple.com/library/ios/documentation/Cocoa/Reference/Foundation/Classes/NSURLRequest_Class/#//apple_ref/occ/clm/NSURLRequest/requestWithURL:) so we need to find a way to integrate with that, otherwise setting a timeout higher than the native value on the JS side won't work.

@nicklockwood Thanks for reviewing.
It seems that the specification for XMLHttpRequest, if not given a timeout, is to wait indefinitely. That being said, we could just set the native request to never timeout.
However, after running a couple tests in chrome, it seems that XMLHttpRequest will timeout after 4 minutes flat and not wait indefinitely (I can provide code if anyone want to test this themselves). Reading a little bit deeper, from that same page:
If you set an XMLHttpRequest time-out value that is larger than the network stack's time-out value,
the network stack will time out first and the ontimeout event will not be raised.

This is sort of the current behavior with our XMLHttpRequest in that it times out after 60 seconds. So the question is should an unspecified timeout value never time out, or should it have a reasonable default like chrome?
What are your thoughts on this? I haven't tested it yet, but does anyone know the default native timeout for android?

I think it's reasonable to have a default and/or maximum timeout period rather than waiting forever if no timeout is specified, but I also think that the native stack timing out should appear the same way as a JS-set timeout.
With the current implementation, the native stack timing out will appear as an error, and won't fire the ontimeout handler.
If you'd prefer not to mess with the native code in this PR though, we could just implement the JS side to always set the timeout to <= 60s, then you should always get a timeout instead of an error.
We should also probably verify that the native default timeout on Android is the same.

Doing this natively seems right to me since part of the reason of setting a timeout is to release system resources (minimal in this case). Imagine a polling program that issues an XHR with a 1-second timeout and then issues a new XHR after the previous XHR times out -- after a minute the native networking stack would still have 60 open connections.

@ide well, it does call abort() after the timeout, so the native connection should still be cancelled after the JS side times out.
But I agree with you that it feels like timeout should be a native function, since it's already implemented on the native side anyway.

Good point about abort()

@nicklockwood Right now it doesn't actually throw an error if the native stack times out but instead we just get request status of 0 and it doesn't trigger ontimeout (I agree this doesn't seem right, but it's what the XMLHttpRequest specification from msdn says).
Given that I would prefer not to mess with native code in this PR (I can, but would rather do so in the future to ensure it's high quality), I need to set the default timeout (in JS) to <= 60s and then verify that android behaves the same way in order to get this PR accepted? Or is the consensus that it should be implemented natively and this way is not the right way?

I need to set the default timeout (in JS) to <= 60s and then verify that android behaves the same way in order to get this PR accepted? Or is the consensus that it should be implemented natively and this way is not the right way?

What this PR provides right now is implementable by anybody in JS already. If we're going to support the timeout and ontimeout properties, I for one would prefer if we'd hand off the timeout handling entirely to native. Disallowing 0 (to disable) or values over 60s seems half-hearted. Plus, I don't know what the default behaviour of OkHttp is, but I could imagine it's different from NSURLConnection.

In any case, please don't feel discouraged to submit a PR containing native code just because you might think it wouldn't meet the quality bar. We're happy to help. Also, you don't have to solve this problem for both platforms at the same time.

I think I've solved it for both platforms natively. Should I close this PR and submit it as a separate one or force push it here?

@klvs if you can update this one then it would be nice to keep the discussion and history. But if it's easier to create a new PR you can always refer back to this, so I think it's fine either way.

@klvs Do you want to address the comments above and rebase this to make sure tests pass?

This is actually outdated and should be closed. It was addressed in #5038. Sorry for the straggling PR.


[Reolink] Implement continuous AI detection tracking

Check cam AI detection state through GetAiState API calls doing periodic polling to send events to MQTT when AI detection state changes.
Now this is done only while movement is detected using ONVIF motion events.

Already implemented.


Embeddable outcomes

Create a Svelte component that lets someone easily embed an outcome on their webpage. Eventually this will be the basis for how CheckIt outcomes can be embedded in things like PreTeXt books.

Implemented at 2410cfd0b9f83925958768695bac7a5a3695f598


Values logged in test_epoch_end not returned when calling test()

🐛 Bug
When calling test(), if values are logged only in the test_epoch_end method they are not returned. This leads to the following somewhat inconsistent behaviour:

Values logged only in step method -> appear in list returned by test().
Values logged in step and epoch_end -> both appear in list returned by test().
Values logged only in epoch_end -> values do not appear.

Please reproduce using the BoringModel and post here

https://colab.research.google.com/drive/1C1UiT815EAP6CGZcumhQ_JP8RMVBdFpX?usp=sharing
Expected behavior
If values are logged only in epoch_end they should be returned by test().
Environment
PL version: 1.0.2
see colab.

@SeanNaren mind have look? :]

Thanks for the report @pbmstrk! Fairly simple but with a couple of ways to fix this.
The issue arises because when we log metrics, we do not include any custom logged epoch end metrics. The reason why this is included when something happens within the test_step function is because we actually complete the loop here which reduces step metrics per dataloader.
At this line we add everything in callback_metrics which includes our custom logged metric in test_epoch_end.
Solution 1
Add the below lines in the step metrics calculation in logger_connector.py, replacing the simple continue operation:
if len(self.callback_metrics) > 0:
    self.eval_loop_results.append(self.callback_metrics)
continue

The issue with this solution is that if we had multiple data-loaders, our custom metric will be added to every result for each data-loader.
will return with multi dl:
[
    {
        'y/dl1': 1.4e-4,
        'custom_metric': 0.4
    },
    {
        'x/dl2': 1.8e-3,
        'custom_metric': 0.4
    }
]

Solution 2
Add the below lines after the step metrics calculation, creating a separate entry in the return Results List for custom metrics. I.e add after the dataloader metrics loop:
                if len(self.callback_metrics) > 0:
                    self.eval_loop_results.append(self.callback_metrics)

will return:
[
    {
        'y/dl1': 1.4e-4,
    },
    {
        'x/dl2': 1.8e-3,
    },
    {
        'custom_metric': 0.4
    }
]

Will implement solution 1, as this reflects what we see if there are step logging.

Hi @SeanNaren!
It seems this issue happens again starting from PL version>=1.5.5. Could you please have a look?


Value with opposite sign silently produced by mj_saveLastXML when joint limit is really big and positive (~1e38)

Minimum Working Example (available at https://gist.githubusercontent.com/traversaro/a07efb8c9448ade704d8aace46f17e6f/raw/79e6aa32f0fdfa8558e5859bbe2ab7f22bcd966c/reproduce.py):
wget https://gist.githubusercontent.com/traversaro/a07efb8c9448ade704d8aace46f17e6f/raw/79e6aa32f0fdfa8558e5859bbe2ab7f22bcd966c/reproduce.py
python reproduce.py

on Ubuntu 22.04 with apt dependencies, both with 3.0.1 and https://github.com/google-deepmind/mujoco/commit/0d37670698b49e78594c635b7f54682ce51ec95d it fails with output:
<mujoco model="cartpole">
  <compiler angle="radian"/>
  <statistic meansize="0.5" extent="2" center="0 0 0.25"/>
  <worldbody>
    <body name="pole">
      <inertial pos="0 0 0.5" mass="0.1" diaginertia="0.00833396 0.00833396 1.25e-06"/>
      <joint name="pivot" pos="0 0 0" axis="1 0 0" range="-2147483648 -2147483648"/>
    </body>
  </worldbody>
</mujoco>

Traceback (most recent call last):
  File "/home/traversaro/idyntreepypi/reproduce.py", line 38, in <module>
    mj_model = mujoco.MjModel.from_xml_string(model_mjcf_string)
ValueError: Error: range[0] should be smaller than range[1] in joint 'pivot' (id = 0)
Object name = pivot, id = 0, line = 7, column = -1

The problem is that for some reason the URDF joint:
        <limit effort="500.0" velocity="10.0" lower="-3.4028234663852886e+38" upper="3.4028234663852886e+38"/>

get translated in the mjcf joint:
      <joint name="pivot" pos="0 0 0" axis="1 0 0" range="-2147483648 -2147483648"/>

While in theory one on the URDF side could use a continuous joint instead of a revolute joint with such huge limits, if the number it is too great to parse it would be great if there was an error or at least a warning instead of silently using a wrong value.

cc @flferretti

Digging a bit deeper, this seems to be some kind of saturation with a 32-bit integer. That could make sense, but what is quite surprising is that for some reason any big number >= 1e10 gets saturated with a negative value, i.e. -2147483648.

Do you want to put a breakpoint here and step through? I expect this should not be hard to figure out. If not, we'll get to it at some point.
Thanks!

Thanks for the pointer! It seems that the value is correctly loaded in memory, so I guess the problem is in the export (i.e. mj_saveLastXML).

Thanks for this, fix incoming.

Great, thanks a lot!


POP3 support

I'd like to see POP3 support.

As POP3 become more and more obsolete we're not going to support it. Sorry.


Support full podtemplate spec for affinity assistant pod

Feature request
Right now, we can provide the complete set of field for taskrun pods and also assinity assistant pods using the configmap here default-pod-template and default-affinity-assistant-pod-template
From the documentation provided here it gives a perception that you can provide all the fields in config-defaults configmap for both pod-template and affinity-assistant-pod-template and can also override three fields (tolerations, nodeSelector, and imagePullSecrets) mentioned in documentation from taskrun and pipelinerun podtemplate which you provide during taskrun and pipeinerun creation.
However, when I tried this feature, it looks like only the three fields  (tolerations, nodeSelector, and imagePullSecrets) from the default-affinity-assitant-pod-template are getting populated in the pod. I tried to figure out the code and see only these three field are getting read by the controller from default-affinity-assistant-pod-template https://github.com/tektoncd/pipeline/blob/main/pkg/apis/config/default.go#L156 and https://github.com/tektoncd/pipeline/blob/main/pkg/apis/pipeline/pod/affinity_assitant_template.go#L29
We should support all field for the default value provided in config-defaults configmap and make documentation more clear.
Use case
Use case is to provide the same podtemplate for both taskrun pods and assifnity assistant pod, so fields like priorityClassName can be provided and all pods get same priority value to schedule.

@chenbh Any thoughts on this? Any specific reason we did not expose all the fields? cc @vdemeester


DocsArchive-<IP_ADDRESS>Auto archive content

Please don't merge this PR until target archive repo PR https://github.com/OPS-E2E-PPE/docs-archive-test-target/pull/1071 is merged into live branch.
Auto archive content to https://github.com/opstest2/docs-archive-test-target.git

Docs Build status updates of commit 18de24d:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error: RepositoryUnauthorizedWithSourceCommit] Git data access to 'https://github.com/opstest2/docs-archive-test-source' (branch: Release_Archive_main_2022-02-22-01-52-44) is not authorized.. It looks like this might be the first time user: v-alji submitted a pull request to this repo. Before user can run builds in a pull request, he/she can enable 'v-alji' GitHub account in Docs by visiting Docs Portal (https://ops.microsoft.com). After enabling his/her account (v-alji), close and then reopen this pull request to start another build.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


How to read request method from response

I'm writing a hook on fetch response. I need both the URL and the method of the request to decide whether the hook should be called or not.
However, in the response hook, I can only get URL. Do you know where could I get the method('post', 'get', 'put', etc.) that the request is using in the response hook?
fetchIntercept.register({
  response: function(response) {
      if(response.url === predefinedURL   &&   response.method /* I don't know how to get it */  === predefinedMethod) {
           //do something here
      }
  }
});

Many Thanks

This is currently not possible you can take a look at the angular $http inteceptors how they doing something like this.

Thanks. I guess the only way around is to proxy fetch. I end up writing some code like this:
window.fetch = (function(oldFetch) {
  if (oldFetch.__mocked__) {
        return oldFetch
  } else {
        var mock = function(url, config) {
              var custom = {url, config};
              return oldFetch(url, config).then(function(res) {
                    res.__params__ = custom;
                    return res;
             });
        mock.__mocked__ = true;
        return mock;
  }
})(window.fetch)


Incorporate pisa - part 1

Basic version: As soon as env.PISA_URL is set, pisa is used.
Extended version: For our preview-deployments and "main" a special env.ENABLE_PISA_ONLY_ON_PISA_BRANCH is introduced - in order to have pisa only running on https://pisa.scrivito-portal-app.pages.dev. This env is already set for this project in Cloudflare pages.
Of cause more modules will follow, once we agree on the basic mechanism.

REVIEW (295a3fc)


Create a test fetch

A mock fetch that can be used for unit testing of apps using the library. It should have a hook where the user can check what is the response, and they can define a response.

Maybe in datx...


Issue-Adds refresh for news feed

Automated Review Comments
Issues in src/components/Header.tsx:

(2, 'Hardcoded string found')
(15, 'Hardcoded string found')
(18, 'Hardcoded string found')
(19, 'Line exceeds 80 characters')
(19, 'Hardcoded string found')
(20, 'Line exceeds 80 characters')
(20, 'Hardcoded string found')
(21, 'Line exceeds 80 characters')
(22, 'Line exceeds 80 characters')
(22, 'Hardcoded string found')
(23, 'Hardcoded string found')
(25, 'Line exceeds 80 characters')
(25, 'Hardcoded string found')
(33, 'Hardcoded string found')
(36, 'Hardcoded string found')
(37, 'Line exceeds 80 characters')
(37, 'Hardcoded string found')
(38, 'Line exceeds 80 characters')
(38, 'Hardcoded string found')
(39, 'Line exceeds 80 characters')
(40, 'Line exceeds 80 characters')
(40, 'Hardcoded string found')
(41, 'Hardcoded string found')
Issues in src/components/api/newsFeed.ts:
(19, 'Line exceeds 80 characters')
(19, 'Hardcoded string found')
Issues in src/components/news/NewsFeed.tsx:
(2, 'Hardcoded string found')
(3, 'Hardcoded string found')
(24, 'Hardcoded string found')
(28, 'Hardcoded string found')
Issues in src/components/news/NewsItem.tsx:
(2, 'Hardcoded string found')

I got it.


yakut compile deletes directory initially

It seems that it will delete the output directory first, so if the DSDL namespace you're working on is directly in the working directory, it will delete the directory, and have no files to work on, quitting. It will output a warning, but only after deleting the namespace.
IMO the warning should be changed to an error, with a suggestion to nest the namespaces down a level, if the current behaviour of clearing the output directory is to be kept.
Simple reproduction
git clone https://github.com/UAVCAN/public_regulated_data_types
yakut compile public_regulated_data_types

It was fixed about two months ago: https://github.com/UAVCAN/pyuavcan/pull/138
Please make sure you are running the latest software

I don't get this issue in pyuavcan, which signifies it's a different problem somehow
I've reproduced it with fully updated packages in a fresh venv

pydsdl == 1.10.1
pyuavcan == 1.1.3
yakut == 0.1.5

The issue is here: https://github.com/UAVCAN/yakut/blob/9aee303db539e07b023458c51bf7325e744f0f6c/yakut/cmd/compile.py#L179

I somehow managed to introduce the same bug in two different places. Sigh. I just fixed it in the orchestration branch, let me put up a PR.


CVE-2020-28374: SCSI "EXTENDED COPY" (XCOPY) requests sent to a Linux SCSI target (LIO) allow an attacker to read or write anywhere on any LIO backstore

More details are available at https://www.openwall.com/lists/oss-security/2021/01/12/12, but here's the full description:
SCSI "EXTENDED COPY" (XCOPY) requests sent to a Linux SCSI target (LIO) allow an
attacker to read or write anywhere on any LIO backstore configured on the
host, provided the attacker has access to one LUN and knowledge of the victim
backstore's vpd_unit_serial (AKA "wwn"). This is possible regardless of the
transport/HBA settings for the victim backstore.
- with vhost-scsi this can allow VM guests to read or write to images assigned
  to other qemu processes
- with iSCSI this allows CHAP, ACL and network portal isolation bypass
- backstores with no corresponding transport LUN mapping remain vulnerable
- all other LIO transports and backstores which allow for XCOPY processing by
  LIO's target_core_xcopy handler should be considered vulnerable
- tcmu-runner based user backstores are also vulnerable via a similar logic bug

This is due to the way that LIO behaves when processing XCOPY
copy-source/copy-destination (CSCD) descriptors; when attempting to match
CSCD descriptors with corresponding se_devices, target_xcopy_locate_se_dev_e4()
iterates over LIO's global devices list, which includes all configured
backstores, instead of only considering backstores which are exposed to the
initiator via transport layer ACL settings.

Similarly, when LIO is configured to forward SCSI requests to the user-space
tcmu-runner daemon (via target_core_user), tcmu-runner's xcopy_locate_udev()
iterates over all tcmu-runner devices, without considering any transport layer
restrictions.

SuSE has a patch available at https://bugzilla.suse.com/show_bug.cgi?id=1180676, and I'm also attaching it here. Please let me know if you'd like a proper PR instead:
@@ -, +, @@
---
 tcmur_cmd_handler.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)
--- a/tcmur_cmd_handler.c
+++ a/tcmur_cmd_handler.c
@@ -1349,6 +1349,18 @@ static int xcopy_parse_parameter_list(struct tcmu_device *dev,
        if (ret != TCMU_STS_OK)
                goto err;

+       /*
+        * tcmu-runner can't determine whether the device(s) referred to in an
+        * XCOPY request should be accessible to the initiator via transport
+        * settings, ACLs, etc. XXX Consequently, we need to fail any
+        * cross-device requests for safety reasons.
+        */
+       if (dev != xcopy->src_dev || dev != xcopy->dst_dev) {
+               tcmu_dev_err(dev, "Cross-device XCOPY not supported\n");
+               ret = TCMU_STS_CP_TGT_DEV_NOTCONN;
+               goto err;
+       }
+
        if (tcmu_dev_get_block_size(xcopy->src_dev) !=
            tcmu_dev_get_block_size(xcopy->dst_dev)) {
                tcmu_dev_err(dev, "The block size of src dev %u != dst dev %u\n",
--

Looks addressed via https://github.com/open-iscsi/tcmu-runner/pull/644

Looks addressed via https://github.com/open-iscsi/tcmu-runner/pull/644

Resolved via #644

Resolved via #644


Move on to semver major.minor.patch and off -alpha

This library hasn't seen any updates since June, and new libraries such as pin-project and pin-project-lite have since sprung up, rounding out the library space around pinning.
I'd like to propose we move off the -alpha prefix, and to a less volatile release channel, because -alpha versions will always be updated by Cargo which isn't great. In fact, I'd like to propose we move this library to semver major-minor-path so changes can be more accurately communicated, which seems desirable for a library that's underpinning (heh) the entire async ecosystem.
I hope this makes sense. Thanks!

See #26 moving to 0.1.0.

Fixed in https://github.com/rust-lang-nursery/pin-utils/pull/26, releasing now.


the latest code is not working, have any plan to fix it?

Thank you for reporting it! I will try to fix it in the next few days.


HDK – Training Digital Thread

We're required to learn about using the Digital Thread methodology with System Composer, Requirements Toolbox, and Simulink Test.
We've got a hands-on:

https://github.com/icub-tech-iit/training-systemcomposer-pendulum

Here are the slides:

mbse-systemcomposer.pdf

In particular, take a look at the resources linked from within the last page:

cc @Nicogene @Lawproto @ale-git @martinaxgloria


do not get single service on one host?

hi: http_server do not support for getting single service?
but the comment at the http_service as below.
'''
Get a view of a single service on one host.
Shows all of the variables for the host object.
'''

yes, I'm curious about the same thing. Can you add a comment for URL_REGEX?
https://github.com/zorkian/nagios-api/blob/master/nagios-api#L41
Is this project dead?

I wouldn't say it's dead, I just don't use it in my day to day anymore so I haven't been doing any development. (At Dropbox we have ~100 Nagios shards with enough data that this project doesn't work in any reasonable speed, so we've started using the Thruk frontend + our own custom inhouse monitoring system.)
So, I definitely read comments and PRs, usually. Sometimes I miss them, but I'm happy to be poked and to respond. :)

Oh cool. Thruk offers an rest interface as well as a modern web interface?


Add ES translation of Bootstrap Waypoints

Closes #4540
Thanks to @vtamara for the revision.

I just suggested minor corrections. Good job!

Thanks @vtamara! I think I got lazy on the proof read before pushing this one. I corrected most of the changes you suggested. If there's no objection, I think it's ready for merging.

@justinian336 @vtamara is this ready to be merged?

Yes, we agred with Quincy to merge the whole spanish translation and micro-manage corrections after.  Besides @justinian336 already applied almost all the corrections I suggested.

Sounds good, merging! :+1: