Example pipeline for Bio-Formats

Following on from https://twitter.com/rabernat/status/1346849632484257800, feel free to ignore/close/delete as appropriate.
Source Dataset

Any number of bio-imaging filesets which can be parsed by github.com/ome/bioformats, which parses over 150 different file formats. A large number of format-organized files (1-2 TB) from our daily test suite can be found under https://downloads.openmicroscopy.org/images/, downloadable via HTTP.
Public, CC-BY, reference data (0.15 PB and growing) which it would be valuable to store publicly can be found under https://idr.openmicroscopy.org/. Each study organizes its data differently and would likely be captured by a separate pipeline. Download would currently be most efficient using Aspera but we will be migrating the input files to S3. Note, however, that the input for each single image may need to be a list of files, e.g.
def generate_zarrs(filesets: List[List[str]]) -> List[str]

Transformation / Alignment / Merging

bioformats2raw will turn any @bioformats-supported file into an OME-Zarr.
rechunking may be necessary for various interactive scenarios (2D vs 3D)

Output Dataset

Each OME-Zarr output (potentially multiple from a single set of inputs) follows the specification available under https://ngff.openmicroscopy.org/latest/
An initial example from Jan. 6. 2020 can be found in https://gist.github.com/joshmoore/31303ef65820b8af5728d92a4f2d9b51

I'm trying to understand this use case better. Are you hoping to do

one legacy file --> one zarr

or

many legacy files --> one zarr

bioformats2raw will turn any @bioformats-supported file into an OME-Zarr.

This seems like a powerful tool. One challenge we will run into is that Pangeo Forge wants to manage the parallelism, so it's best if the individual steps in a pipeline are single-threaded and can fit in memory. This is most relevant to the second scenario (many files --> one zarr). In this case, can you imagine a workflow that builds up a big zarr incrementally? The new Tutorial may help you understand how we envision things working.

I'm trying to understand this use case better. Are you hoping to do

one legacy file --> one zarr

or

many legacy files --> one zarr

bioformats2raw will turn any @bioformats-supported file into an OME-Zarr.

This seems like a powerful tool. One challenge we will run into is that Pangeo Forge wants to manage the parallelism, so it's best if the individual steps in a pipeline are single-threaded and can fit in memory. This is most relevant to the second scenario (many files --> one zarr). In this case, can you imagine a workflow that builds up a big zarr incrementally? The new Tutorial may help you understand how we envision things working.

Are you hoping to do ...

The simple answer is probably "many legacy files", but we tend to work in filesets. I.e. many proprietary image formats inherently use multiple files for one acquisition.

best if the individual steps in a pipeline are single-threaded and can fit in memory.

There are definitely knobs to make things single-threaded. But there's currently, no real way to communicate to pangeo what the task breakdown is, since it's very not as straight-forward as "one file per timepoint". I think it would require a code update to allow (a) querying how many tasks there are and (b) adding a --task=N flag, but the overhead of something like that could be significant.

Are you hoping to do ...

The simple answer is probably "many legacy files", but we tend to work in filesets. I.e. many proprietary image formats inherently use multiple files for one acquisition.

best if the individual steps in a pipeline are single-threaded and can fit in memory.

There are definitely knobs to make things single-threaded. But there's currently, no real way to communicate to pangeo what the task breakdown is, since it's very not as straight-forward as "one file per timepoint". I think it would require a code update to allow (a) querying how many tasks there are and (b) adding a --task=N flag, but the overhead of something like that could be significant.


nullability specifier 'nonnull' conflicts with existing specifier  'nullable' - ionic ios build

Describe the bug
I am trying to build my ionic ios app and getting the following error
Plugins/cordova-plugin-fcm-with-dependecy-updated/AppDelegate+FCMPlugin.m:146:101: error:
      nullability specifier 'nonnull' conflicts with existing specifier
      'nullable'
  ...)messaging didReceiveRegistrationToken:(nonnull NSString )deviceToken {

To Reproduce
Steps to reproduce the behavior:

sudo npm install
sudo gem install cocoapods
pod repo update
ionic cordova build ios

Expected behavior
Build should be successful.

This has been fixed.

I've upgraded to v7.4.0 but still get this error. This exact same error

Same issue as above for me, latest version of plugin at time 7.7.0 - the workaround above also works to get past the error - though I'm not sure what the implications are and I've not yet had the chance to test the functionality on IOS.

Same issue here. The latest version (7.7.0) displays this error:
https://imgur.com/zhXEpBo


Pages render Twice

Steps to reproduce

Add a route block in page component

<route lang="yaml">
meta:
  layout: layout_name
</route>

Put a console.log('Hi! Render Page!!') in setup method of component
See the message twice in the dev tools

This also heppen in the vitasse starter template
Aditional context
Posible related to #4

Yes, I have also encountered this problem.

I want to add more input to this, it looks like the component is first rendered without the layout then the layout is loaded and this reload the component, you can check this by adding a console.log('layout setup') inside the layout setup function.

This must also be related to #11

I applied the hotfix mentioned in of changing const name = ref('defualt') to const name = ref('') which fixes the fact that the default layout always renders, but then theres someting more happening when you change a page using vue router first the plugin changes the layout before even the navigation is triggered which causes the page component to be reload then vue router changes the page and the new page is rendered.
This probably need a new bug report.

Well, the layout change happens before the route change. That's because right now a template update is triggered with a beforeEach() hook. So I throttled my connection speed which makes it very apparent.
The page is displayed while the template is already changed. And If you have a template already in cache and you need a while to load the page, it can become a bit wonky.
I applied the following and it seems to fix it for me. Please test this and see if everything works as expected.
In your node_modules/vite-plugin-vue-layouts/dist/index.js change these lines
(Line 72)
-    router.beforeEach(async (to, from, next) => {
-      await updateLayout(to.meta?.layout)
-      next()
+    router.afterEach((to, from) => {
+      updateLayout(to.meta?.layout)
    })

So found that this bug still exists ( When I render the page the first time everything is good but when I change the route and return back it renders twice


Scatter gradient implementations

Not sure if this is an issue or I'm just holding it wrong :-) I've got an alternative approach that seems to work with gradients by building up my output up by catting slices into my tensors, which does seem to work for the grads.
I have two tensors (token_embeddings and image_features), I want to interleave them in some way. It's for a llava like model, so my input tokens are like
   [
       [this, is, an, <image>],
       [two, images, <image>, <image>],
   ]

where <image> is a sentinel token. What I've got to so far is making my output a flattened tensor [batch * max_seq, dim] my token/image tensors [num_tokens, dim] and [num_images, dim] and forming indices to assign to, ending up looking like this:
output = mx.zeros(batch * max_seq, dim)
output[token_ix] = self.embeddings(token_ids)
output[image_ix] = image_features

It doesn't seem like I can get gradients for this though:
def fn(x):
    output = mx.zeros([4])
    output[mx.array([0, 1])] = x
    return output.sum()

x = mx.array([2,3])
print(fn(x))

grad_fn = mx.grad(fn)
print(grad_fn(x))

gives me
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
Cell In[310], line 10
      7 print(fn(x))
      9 grad_fn = mx.grad(fn)
---> 10 print(grad_fn(x))

ValueError: Primitive's vjp not implemented.

Like I said, it seems like there's an alternative in catting things since:
def fn(x, y):
    val = mx.concatenate([x[:1, :], y[:, :], x[1:, :]])
    return val.sum()

x = mx.array([[2,3], [4, 5]])
y = mx.array([[2,3], [4, 5]])
print(fn(x, y))

grad_fn = mx.grad(fn)
print(grad_fn(x, y))

seems to work.

Scatter vjp is indeed missing from main at the moment. I started an implementation in the branch scatter-vjp so that you can be unblocked. The VJP for assignment is the only one implemented so far and not particularly well tested.
Depending on the number of assignments and the size of the assigned blocks concatenating slices might not be too bad of an implementation however.
On that branch the following worked fine:
import mlx.core as mx

def fn(x):
    output = mx.zeros([4, 128])
    output[mx.array([0, 1])] = x
    return output.square().sum()

x = mx.random.normal(shape=(2, 128))
print(fn(x))
# array(274.507, dtype=float32)

grad_fn = mx.grad(fn)
print(grad_fn(x))
# array([[1.08186, -1.9959, 1.18484, ..., 2.52877, 0.80407, 0.529424],
#        [-0.74177, -1.64652, 0.113564, ..., -1.66786, 1.31119, -0.58756]], dtype=float32)

Closing as this is now merged. Scatter multiply, max, min are still missing but assign and add are there.


NoSuchMethodError: tried to call a non-function, such as null: 'dart.global.firebase.messaging' in Flutter

I got the error (this one didn't bring the error screen for my run
web application, which I stumbled upon while inspecting the debug console) NoSuchMethodError: tried to call a non-function, such as null: 'dart.global.firebase.messaging'.
 The last sentence in their error is not dart.global.firebase.messaging.
How can I fix this error? Appreciate if someone can advise. Thank you in advance!

I found a solution. When I updated firebase_messaging to a newer version, this error went away!


Troff

BUILDME will build troff assuming you have $APEX and $HARVEY set. I'm not sure how to turn this into a build.json format.

Commits a6ff1e08876378dfe6549a550bae4167790165f1 and 2151ee173855467c998855df05869fa4f18aacac are not signed-off.
Please fix these issues:

John Floren has not signed-off a6ff1e0.
John Floren has not signed-off 2151ee1.

If you'd like more information on how to sign your commits please visit signed-off-by.me


[Branch fix] Merging main back in develop

We merged PRs directly into main by mistake. Correcting this.
NB: we need to switch the default branch to develop

@fmalatino Data named has changed on the datashare which leads to ci breakage. Please force merge this and I will PR a fix to the ci to develop next


Is it possible to build a AST with this method

I am really curious about your design.
I am having a hard time wrapping my head around some aspects of it. But I was curious about your thoughts of using an approach like this to build AST output.
I see a lot of JSON to AST parsers for example, and they don't do anything as nifty.
If this is not the right direction, can you point me in a better direction?

see https://github.com/yelouafi/create-a-simple-functional-language for examples. Basically you use token to parser basic lexemes and  .map or .apply to transform the parsed strings into more structured output
Note this is not an industrial strength parser, it's more a thing for language amateurs. If you want something suited for production you may take a look at https://github.com/jneen/parsimmon

TYVM


error occurred during stop cluster

Can be reproduced ?
Yes (Occasionally)
Steps:
Start a cube cluster and call stop
Expected behavior:
shutdown properly
Actual behavior:
throws  [fatal] [raftstore]: shard 1042 add apply committed entries job failed with Stopper is unavailable
Environment:

Version or commit-id (e.g. v0.1.0 or 8b23a93):
Hardware parameters:
OS type:
Others:

Configuration file:
Additional context:

Error message from client:
Server log:
Other information:

run more rounds of the test, this error still can be reproduced occasionally(20/100).


[ci skip] [cf admin skip] NO_CI Update dependencies using grayskull

Automate the dependency pin updates using grayskull. See https://conda-forge.org/docs/maintainer/conda_forge_yml.html#bot
Reduces the need for manually updating pins during bot updates, e.g. commits 74b8b2df71f6fd385e78b375c531f51de7878aa9 and 11acfb2f9c80bfa57623032288c8e78c2632290d in #8.

Checklist

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

@conda-forge-admin, please rerender

@weiji14 nice, could you please send the same PR also for TorchMetrics and other lightning packages... 🙏

@weiji14 nice, could you please send the same PR also for TorchMetrics and other lightning packages... pray

Yes, I'll put it on my todo list!


WIP: rocAL - Tf pets training

@there are 162 file changes in this because tot might have changed. Please update

@swetha097 I tried testing on this docker tag but the training fails:
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/dist-packages/tensorflow/python/client/session.py", line 1378, in _do_call
    return fn(*args)
  File "/usr/local/lib/python3.9/dist-packages/tensorflow/python/client/session.py", line 1361, in _run_fn
    return self._call_tf_sessionrun(options, feed_dict, fetch_list,
  File "/usr/local/lib/python3.9/dist-packages/tensorflow/python/client/session.py", line 1454, in _call_tf_sessionrun
    return tf_session.TF_SessionRun_wrapper(self._session, options, feed_dict,
tensorflow.python.framework.errors_impl.InvalidArgumentError: input depth must be evenly divisible by filter depth: 128 vs 3
	 [[{{node module_apply_default/MobilenetV2/Conv/Relu6}}]]

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/workspace/MIVisionX/rocAL/rocAL_pybind/example/new_api/tf_petsTrainingExample/train_withROCAL_withTFRecordReader.py", line 196, in <module>
    main()
  File "/workspace/MIVisionX/rocAL/rocAL_pybind/example/new_api/tf_petsTrainingExample/train_withROCAL_withTFRecordReader.py", line 165, in main
    train_loss, _, train_accuracy = sess.run(
  File "/usr/local/lib/python3.9/dist-packages/tensorflow/python/client/session.py", line 968, in run
    result = self._run(None, fetches, feed_dict, options_ptr,
  File "/usr/local/lib/python3.9/dist-packages/tensorflow/python/client/session.py", line 1191, in _run
    results = self._do_run(handle, final_targets, final_fetches,
  File "/usr/local/lib/python3.9/dist-packages/tensorflow/python/client/session.py", line 1371, in _do_run
    return self._do_call(_run_fn, feeds, fetches, targets, options,
  File "/usr/local/lib/python3.9/dist-packages/tensorflow/python/client/session.py", line 1397, in _do_call
    raise type(e)(node_def, op, message)  # pylint: disable=no-value-for-parameter
tensorflow.python.framework.errors_impl.InvalidArgumentError: Graph execution error:

Detected at node 'module_apply_default/MobilenetV2/Conv/Relu6' defined at (most recent call last):
Node: 'module_apply_default/MobilenetV2/Conv/Relu6'
input depth must be evenly divisible by filter depth: 128 vs 3
	 [[{{node module_apply_default/MobilenetV2/Conv/Relu6}}]]

Original stack trace for 'module_apply_default/MobilenetV2/Conv/Relu6':


[WIP] Add exokit-home keyboard+menu for MLO

This PR ports the keyboard + url menu from exokit-home to be used with Magic Leap One.

[x] add controller rays/pointers
[ ] add controller position tracking
[ ] add ray/pointer key interaction under onselect
[ ] debug canvas-text related things that are causing crash:

ctx.font = `${fontSize}px Arial`;
ctx.fillText(urlState.text, 10, urlBarHeight - 10*2 - 30);
const {width: barWidth} = ctx.measureText('[');
const {width} = ctx.measureText('[' + urlState.text.slice(0, i) + ']');

The backtrace from gdb debugging the font crash:

Thanks, I figured it was the fonts. I actually don't know what the native font support is on MLO, but Skia seems to be exploding on this.
Either we can use the Android font system or we need to use some other supported libs.
Next steps is probably:

Figure out the exact call the explodes, with skia logging
Research why/what alternatives there are
Move to a font system that is in the collection of libs in the MLSDK, which I'm presuming there is

Inspirational code from Servo: https://github.com/servo/servo/pull/21985/files#diff-d526bc10d7ec14d71e70023ce474ea3fR130

Freetype work is being PR'd at: https://github.com/modulesio/skia/pull/2

Closing now, the work was completed at #547

Closing now, the work was completed at #547

Closing now, the work was completed at #547

Closing now, the work was completed at #547

Closing now, the work was completed at #547

Closing now, the work was completed at #547

Closing now, the work was completed at #547


Arms fall off (R6)

I feel like you should start updating this script more. Its been a year and I cant find a solution to this problem

Fixed in v2


BouncyCastle vulnerable to a timing variant of Bleichenbacher called Marvin Attack

(As I've sent to the security mailing list three emails, last one over 2 weeks ago, and haven't received anything but automated reply that the email was received, I'm making the issue public here. What follows after the question is a verbatim copy of the last email.)
Question: Should I ask for CVE assignment for it?
I've tested both PKCS#1 v1.5 and OAEP API and verified that both provide
a clear side-channel signal useful in Bleichenbacher-like attacks.
Since my previous emails have received nothing but an automated reply
for over a week, I'll be making this issue in BouncyCastle public in
two weeks (on 6th of November) if that doesn't change.
I've tested bcprov-jdk18on-17.jar on OpenJDK 1.8.0_372 from ArchLinux on
an AMD Ryzen 5 5600X CPU. I did not perform any special tuning to
make the noise smaller.
I've used the test harnesses in attachment to run the test data generated
by the step2-alt.sh and step2-oaep-alt.sh from
https://github.com/tomato42/marvin-toolkit/
(though I did test just 2048 bit keys, not the 1024 and 4096 generated by
them too).
Both of them accept 3 parameters: a path to a RSA PKCS#8 DER key, path to
a file with concatenation of RSA ciphertexts (they both assume those are 256
bytes long), and an output csv file where timing of the processing will be
written. See the examples/pyca-cryptography in the above repo on how to
process that csv file further.
For both padding modes the Friedman test p-value is smaller than what
a double precision floating point number can represent (i.e. it's reported
as 0).
That's in spite of using just 10k and 100k sample size for pkcs1 and oaep
test respectively.
Which means the timing signal is extremely strong and definitely exploitable
over the network.
Looking more closely at the results, it's clear that the PKCS#1 interface
leaks timing data through raising of an exception, and the OAEP interface leaks timing data through the bit size of the decrypted value (EM in PKCS#1
nomenclature). Though those are very imprecise results, additional
side-channels may be present.
See the Marvin paper for suggestions how to fix this:
https://people.redhat.com/~hkario/marvin/
A bit more information is also present in the draft specifying the
RSA implicit rejection mechanism I'm working to standardise:
https://github.com/tomato42/marvin-ietf
See step2.py for explanation of the meaning of the probes, the legend for
pkcs1.png is as follows:
ID,Name
0,header_only
1,no_header_with_payload_48
2,no_padding_48
3,no_structure
4,signature_padding_0
5,valid_0
6,valid_48
7,valid_192
8,valid_246
9,valid_repeated_byte_payload_246_1
10,valid_repeated_byte_payload_246_255
11,zero_byte_in_padding_48_4

for oaep.png is as follows:
ID,Name
0,no_padding_48
1,no_structure
2,signature_padding_0
3,too_short_payload_0_1
4,too_short_payload_0_3
5,too_short_payload_0_7
6,too_short_payload_0_15
7,valid_0
8,valid_repeated_byte_payload_245_0

pairwise sign test and Wilcoxon signed rank test results are in the csv files:
oaep.csv
pkcs1.csv
Code:
OAEPDecryption.txt
PKCS1Decryption.txt

Apologies about the delay in responding, we only check the address every couple of weeks and it gets more than its fair share of spam. We've found your original emails though with the attachment. Taking a look.

We've done an initial pass.
If you're up for it, we're interested in following this up by looking at what our TLS API is doing.
While the figures around the examples are interesting, the issues related to exception throwing on javax.crypto.Cipher are well known, and it's a function of the JCE API rather than the BC provider, which in this case is simply following the documented API.
The BCJSSE provider does attempt to work around things already, but it's quite likely with better analysis we could find a way of doing that better as well. We will try and put something together for collecting timing data using your tools and be back in touch.

It's possible to fix it by not raising an exception, see the implicit rejection documented (a.k.a. Marvin workaround) in the Marvin paper, implemented by OpenSSL, NSS, and proposed in https://datatracker.ietf.org/doc/draft-kario-rsa-guidance/ (I'll be presenting it for CFRG adoption on IETF 118 this Thursday)

Yes, we arrived at that conclusion a while ago - I think with the JSSE we're probably going to need to provide a custom "something" to do it though. Our JSSE provider is used with other JCE providers as well so we'll still need to make sure we can still accommodate them as well. First, collect some numbers though, can't flatten a curve we haven't measured.
Good luck with the presentation.

I think with the JSSE we're probably going to need to provide a custom "something" to do it though

I'm not super familiar with how provider infrastructure in Java works, but isn't it the case that you can either provide a way to do raw RSA operations (i.e. the RSADP() primitive from PKCS#1), or full operations (i.e the complete PKCS#1 v1.5 decryption)?
(I'm genuinely asking, if there are interfaces where implicit rejection won't work, I'd really like to know about them)

So we think, with a "little bending of the rules" we can do this. We can provide raw RSA, but we need to stay mindful of the fact that we're also trying to make it possible for people to certify things, which really rules out raw RSA as a solution, with FIPS and Common Criteria providing developer access to raw RSA is frowned upon, the expectation is that you provide access to full operations only, so as attractive as it is, raw RSA isn't really going to cut it.
We're pretty sure we can still take advantage of implicit rejection though - for example the Java cipher class has an unwrap() method on it which takes a string for the algorithm of the key you want back. @peterdettman pointed out yesterday we could have some special algorithm names which could be used to flag that implicit rejection is acceptable and that exception throwing is not expected, so something like
Cipher rsaCipher = Cipher.getInstance("RSA/NONE/PKCS1Encoding", "BC");

rsaCipher.init(Cipher.UNWRAP_MODE, rsaPrivateKey);

Key secret = rsaCipher.unwrap(encapsulation, "TlsPremasterSecret", Cipher.SECRET_KEY);

Could be used to flag to the provider that "I don't want to see an exception", alternately there's also:
Cipher rsaCipher = Cipher.getInstance("RSA/ImplicitRejection/PKCS1Encoding", "BC");

which could be used to flag the "I don't want to see an exception" mode.
We'll probably need to try a few things and see what works best. Sometimes what looks great in theory doesn't always work well in practice... but there's options.

For FIPS, the PKCS#1 v1.5 will not be allowed at all after end of this year, which is like 6 weeks. So I'm not entirely sure how it's relevant...
For implicit rejection to actually help users of the library, it needs to be the default behaviour.
The legacy depadding may be available for debugging, but it should be documented as inherently insecure.
Also, it's not just about TLS, it affects everything that can use encryption with PKCS#1 v1.5 padding: CMS, JWT, XMLencryption, etc.

Yes, although keep in mind it is PKCS#1.5 encryption they're disallowing and as it's been turned into a soft transition for FIPS 140-2 modules, I've a feeling there may be a bit of a delay on even that being realized fully.
Fully aware it's not just applicable to TLS, have to start somewhere though.

When will you assign a CVE to this issue?

CVE's are not free. We will, and do, raise them when appropriate however the issues with the Cipher API in Java are well documented, and while the numbers are interesting, we haven't come up with anything solid. Our TLS API already incorporates some counter measures and the numbers above are not for our TLS API. We have not found anything which has required the allocation of a CVE.
That's not to say we're not interested in moving to more of the code base making use of what's documented in the RFC that's currently in draft, we big fans of dealing with possible issues early, however that's not even a standard at the moment, and while worthy of investigation is clearly not something we can deploy.
And no, not ever throwing an exception is not an option, we could add a new implementation to do this, but people have being using javax.crypto.Cipher for over 20 years now and there are millions of lines of code relying on this behavior. For all those people the suggested fix is likely to cause other security issues as at that point it will appear the Cipher API has worked but it will be doing so in an application which is not designed to cope with the change in behavior.

CVEs are also the best tool we have to inform users that they are using vulnerable software.
And while I do empathise with having to deal with bad APIs, attackers don't really care why a particular leakage is there, just if it is there.

On a slightly different note, I'll be at the first half of IETF 119 Brisbane, 2024. Is the RFC draft going to be presented again there as a lead up to a vote?

I don't think so. There was a general consensus for the draft adoption by the CFRG at IETF 118. I don't think it will be ready for WGLC by IETF 119, so I'm not sure which vote you mean...
If I'll attend IETF 119, it will be remotely.

the numbers above are not for our TLS API.

The offer to run the test against pure BouncyCastle TLS stack still stands. Provide instructions similar to what I have for other implementations, e.g. go, and I'll run the test against it.

Sure, we'll put something together. You'll just need to give us a few days, we're flat out dealing with certification work at the moment.

ping?

@tomato2 Attached is a copy of the test program I used for the non-JSSE TLS stack. It's based on your original test script, except using the decryption code from https://github.com/bcgit/bc-java/blob/a4e57f2019867c7ee86508fc5b136d73fd4922d9/tls/src/main/java/org/bouncycastle/tls/crypto/impl/bc/BcDefaultTlsCredentialedDecryptor.java#L108 .
(For reference, the JCE version used in BCJSSE is here: https://github.com/bcgit/bc-java/blob/a4e57f2019867c7ee86508fc5b136d73fd4922d9/tls/src/main/java/org/bouncycastle/tls/crypto/impl/jcajce/JceDefaultTlsCredentialedDecryptor.java#L101).
MarvinBC.zip

Yes, that API is vulnerable too, though the side-channel it has is smaller.
After collecting 1M measurements per probe on the same AMD Ryzen 5 5600X I got the following result:
Sign test mean p-value: 0.3052, median p-value: 0.1888, min p-value: 8.685e-54
Friedman test (chisquare approximation) for all samples
p-value: 3.6703623211321894e-88
Worst pair: 1(no_header_with_payload_48), 2(no_padding_48)
Mean of differences: -9.25545e-08s, 95% CI: -1.43365e-07s, -4.362431e-08s (±4.987e-08s)
Median of differences: -1.31000e-07s, 95% CI: -1.50000e-07s, -1.200000e-07s (±1.500e-08s)
Trimmed mean (5%) of differences: -1.25431e-07s, 95% CI: -1.51653e-07s, -1.005266e-07s (±2.556e-08s)
Trimmed mean (25%) of differences: -1.33397e-07s, 95% CI: -1.52282e-07s, -1.161970e-07s (±1.804e-08s)
Trimmed mean (45%) of differences: -1.34690e-07s, 95% CI: -1.51574e-07s, -1.185917e-07s (±1.649e-08s)
Trimean of differences: -1.31000e-07s, 95% CI: -1.55000e-07s, -1.155000e-07s (±1.975e-08s)
Layperson explanation: Definite side-channel detected, implementation is VULNERABLE

legend:
0,header_only
1,no_header_with_payload_48
2,no_padding_48
3,no_structure
4,signature_padding_8
5,valid_0
6,valid_48
7,valid_192
8,valid_246
9,valid_repeated_byte_payload_246_1
10,valid_repeated_byte_payload_246_255
11,zero_byte_in_padding_48_4

pairwise test results:
report.csv.zip
This result suggest that the issue is in the numerical library, just like OAEP result above.

Thanks, @tomato42 . Could you confirm which version of the library that last testing was done with? We released version 1.77 in November where we did some quick improvements on this issue, so it would be great to have comparative results between 1.76 and 1.77.

ran it with bcprov-jdk18on-177.jar and bctls-jdk18on-177.jar

side note: Oracle has released new updates, CVE-2024-20952 is the same vulnerability in Java.

That's interesting, I'd even go as far as to say good news. I'm not sure if this change will affect the timing results you got or not - I think we'll need to try it on an updated JVM.

I haven't looked at the fix in detail, just got a notification that they fixed it

Hi @tomato42,
First a word about SunJSSE and their recent change. While SunJSSE does use Cipher "RSA/ECB/PKCS1Padding" for decrypting the TLS Pre-Master-Secret, it has special code for doing so in that context. The change mentioned above appears targeted at TLS usage only (specifically avoiding an exception throw on an internal codepath), so in case there is any confusion it doesn't seem to be a general fix for timing side-channels in Cipher "RSA/ECB/PKCS1Padding". Presumably it does improve the situation for TLS, which is all good.
The special code I referred to above is that SunJSSE has JDK-specific codepaths. Firstly it requires the passing of a TlsRsaPremasterSecretParameterSpec to the cipher init call (which is also used in UNWRAP_MODE instead of DECRYPT_MODE). This allows it to use a specialized internal implementation tailored to the TLS use case (i.e. not throwing exceptions, and incorporating the RSA version check and the 48 byte random value fallback). As is increasingly common however, TlsRsaPremasterSecretParameterSpec is only allowed for "internal JDK use". Secondly, there is explicit code in the case of any non-Oracle provider to fall back to using Cipher "RSA/ECB/PKCS1Padding" in decrypt mode, with the usual result that it has to catch exceptions for failure. This means that if SunJSSE is used with any other cryptographic provider (than an Oracle one) for the RSA decryption, it is in the same boat as the BCJSSE implementation.
The approach of having a TLS-specific parameterization is IMO good, but it would be great if we (BC) would be able to interoperate with it via some actual publicly accessible variant/version of TlsRsaPremasterSecretParameterSpec.

So, onto the situation in BCJSSE. We have basically two problems to solve.
The first is the Cipher API one (timing signal of thrown exceptions) and we think probably we should replicate the parameter spec trick described above, unfortunately not interoperably as explained, but at least we would have safety when BCJSSE is used with BC, in similar fashion to SunJSSE being safe with JDK.
The second is that we still have an internal timing channel coming from the conversion of a final BigInteger result to a variable-sized byte array. This happens at the end of the blinded RSA decryption. BigInteger has some native code backing for modPow that makes it difficult to give up the performance, but as I recall @tomato42 describing somewhere it's possible to tweak just the final modular multiplication of the de-blinding so that we convert to a fixed-length array without timing dependent on the plaintext. Unfortunately, other parts of this low-level code expect variable-length arrays for RSA values (and this code is heavily locked in by backward compatibility issues). So to address this we basically need to make a self-contained implementation of TLS RSA Pre-Master-Secret decryption, duplicating the bits and pieces currently spread across several RSA and PKCS1 implementation classes, and ironing out the remaining timing channel principally by being able to deal with fixed-length arrays.
Now that I've written all that out, I think I have time to do that second part next week, and we can then use it directly in the non-JSSE TLS stack and get some measurements. The parameter spec solution for BCJSSE would follow by just forwarding to the same implementation in case a specific parameter spec is provided.

The problem with TLS-specific parametrisation is that it is TLS specific. It doesn't help if you use the same API to implement CMS, XMLenc, JWE, or anything similar.
I have some time now so I'll take a closer look at the OpenJDK fix, but on first glance it doesn't look too good...

Unfortunately, other parts of this low-level code expect variable-length arrays for RSA values (and this code is heavily locked in by backward compatibility issues). So to address this we basically need to make a self-contained implementation of TLS RSA Pre-Master-Secret decryption, duplicating the bits and pieces currently spread across several RSA and PKCS1 implementation classes, and ironing out the remaining timing channel principally by being able to deal with fixed-length arrays.

That sounds to me like you need to change the code that does RSA-PKCS#1v1.5, RSA-OAEP, and RSASVE to use a private API for RSA private key operation that returns a byte string instead of an arbitrary length integer.
Signing can still use the old API as the result isn't secret, so leakage that depends on it is fine.

@tomato42 We've added a custom implementation of TLS RSA PreMasterSecret decryption (org.bouncycastle.crypto.tls.TlsRsaKeyExchange#decryptPreMasterSecret, now used by the non-JSSE TLS implementation.
It's available for testing in a new beta build: https://downloads.bouncycastle.org/betas/ (in the bcprov jar).
For timing tests, we can now just collect data for:
byte[] M = TlsRsaKeyExchange.decryptPreMasterSecret(ciphertext, rsaPrivateKey, 0x0303, secureRandom);

Note that this is not a generic RSA//PKCS1 decryption; it validates the expected plaintext length of 48, and also checks the passed version bytes (0x0303 here) match. It may therefore be ideal to test against a ciphertext corpus tailored to the TLS case.

The blinded RSA operation is here: https://github.com/bcgit/bc-java/blob/4ff20f7b2a8aa0341a3e8a82026394b688fec4c2/core/src/main/java/org/bouncycastle/crypto/tls/TlsRsaKeyExchange.java#L176-L197 .
The blinded result is "almost unblinded" using:
BigInteger offsetResult = unblind.add(ONE).multiply(blindedResult).mod(modulus);

where the add(ONE) means that offsetResult will still need to have blindedResult subtracted from it (a final deblinding step) after conversion to byte arrays.

I'm not convinced it's sufficient: the attacks on modexp() exponent leakage generally required at least 64 bits of randomness to sufficiently hide the signal (in exponent blinding). I doubt that 1 bit will be enough.
But I don't know for sure so I'll try to run tests for bcprov-jdk18on-1.78-SNAPSHOT.jar from Mar 5, 2024

How do I convert AsymmetricKeyParameter to RSAKeyParameters?
I've tried this, but it doesn't work:
PmsDecryptBC.zip

You should be able to just cast to RSAKeyParameters.

OK, can't say I see any obvious side-channels.
With 4M measurements per probe and 13 probes (including one that was creating a TLS 1.2 conformant message) I got a negative result with a resolution of about 1.6 ns (on a i9-12900KS @ 5.225GHz):
Sign test mean p-value: 0.4799, median p-value: 0.4741, min p-value: 0.005152
Friedman test (chisquare approximation) for all samples
p-value: 0.285814917961748
Worst pair: 8(valid_246), 11(valid_version_48_3_3)
Mean of differences: 1.24948e-08s, 95% CI: -7.51467e-09s, 3.070419e-08s (±1.911e-08s)
Median of differences: -2.00000e-09s, 95% CI: -4.00000e-09s, 0.000000e+00s (±2.000e-09s)
Trimmed mean (5%) of differences: -2.49367e-09s, 95% CI: -4.44137e-09s, -4.993250e-10s (±1.971e-09s)
Trimmed mean (25%) of differences: -2.84335e-09s, 95% CI: -4.54571e-09s, -1.262384e-09s (±1.642e-09s)
Trimmed mean (45%) of differences: -2.52652e-09s, 95% CI: -4.26733e-09s, -9.139850e-10s (±1.677e-09s)
Trimean of differences: -2.25000e-09s, 95% CI: -4.25000e-09s, -7.500000e-10s (±1.750e-09s)
Layperson explanation: Large confidence intervals detected, collecting more data necessary. Side channel leakage smaller than 1.642e-09s is possible

I'd suggest running tests with enough data to have a 95% CI < 1 ns before calling it completely fixed, but it does look like it's the correct direction.

Just checking, can you tell me what the concern is? 89 to 92 will, or at least should, only throw an exception if the init method rejects the parameter spec (in which case someone's using a non-BC provider, there isn't much we can do at that point). The parameter spec basically sends the provider on the same path as the lightweight version you tested above.

So the line 91 will be successful only if the decryption is done by BC-provider, and the exception handling from 95 onwards is just a fallback for non-BC provider?
If that's the case, I think having line 92 outside this try catch and in a separate block that asserts that no exception is raised by the doFinal, and some more comments that explain which code is expected to execute when, would be good additions. Also, a big warning that the fallback code is not side-channel safe, and instead is "doing its best" to limit, but not eliminate the side-channel leakage I think would be in place.

@pybalo-nex no, the only testing I've did was https://github.com/bcgit/bc-java/issues/1528#issuecomment-1984314416
I recommend testing it yourself, all the tooling necessary is open source, and if you have problems running it, feel free to open issues in tlsfuzzer or marvin-toolkit repos.

We did do some testing of the JSSE fix and got results in line with what @tomato42 found with the lower level code. I'd certainly also encourage independent testing though.
Usually I'd wait till we'd finished the release process for 1.78 (currently unable to tag as waiting on a CVE ID), but this one was assigned CVE-2024-30171. It should appear in the CVE data base shortly after I've been able to do the final tags.

For the record we are currently unable to update the CVE record as Mitre is having issues. It may be a while before the CVE is published but when it is it will show 1.78 as the fix version.

@dghgit BTW, have you tested the OAEP code path?

There isn't an OAEP code path in this case, it's not used in TLS.
That said, yes, after we'd modified the blinding I ran the tools again:
Sign test mean p-value: 0.6092, median p-value: 0.6875, min p-value: 0.00465
Friedman test (chisquare approximation) for all samples
p-value: 0.7767379376442238
Worst pair: 1(no_structure), 6(too_short_payload_0_15)
Mean of differences: -4.97025e-08s, 95% CI: -2.60383e-07s, 1.469225e-07s (±2.037e-07s)
Median of differences: -5.20000e-08s, 95% CI: -7.70000e-08s, -1.500000e-08s (±3.100e-08s)
Trimmed mean (5%) of differences: -2.28183e-08s, 95% CI: -5.88632e-08s, 2.148580e-08s (±4.017e-08s)
Trimmed mean (25%) of differences: -3.54087e-08s, 95% CI: -6.35279e-08s, -5.234820e-09s (±2.915e-08s)
Trimmed mean (45%) of differences: -5.12172e-08s, 95% CI: -7.93227e-08s, -1.933330e-08s (±2.999e-08s)
Trimean of differences: -3.62500e-08s, 95% CI: -6.15188e-08s, -2.812500e-09s (±2.935e-08s)
Layperson explanation: Large confidence intervals detected, collecting more data necessary. Side channel leakage smaller than 2.915e-08s is possible
For detailed report see rsa2048_oaep_repeat/report.csv
With the graph looking like:

Running in a slightly different mode, with exceptions enabled, the results were:
Sign test mean p-value: 0.3602, median p-value: 0.212, min p-value: 0.002113
Friedman test (chisquare approximation) for all samples
p-value: 0.008678135718454017
Worst pair: 2(signature_padding_8), 7(valid_0)
Mean of differences: 6.88133e-08s, 95% CI: -1.84377e-07s, 3.059898e-07s (±2.452e-07s)
Median of differences: 4.80000e-08s, 95% CI: 1.70000e-08s, 7.800000e-08s (±3.050e-08s)
Trimmed mean (5%) of differences: 6.09479e-08s, 95% CI: 2.26257e-08s, 1.065269e-07s (±4.195e-08s)
Trimmed mean (25%) of differences: 5.00174e-08s, 95% CI: 2.40236e-08s, 8.210294e-08s (±2.904e-08s)
Trimmed mean (45%) of differences: 4.46908e-08s, 95% CI: 1.56685e-08s, 7.511880e-08s (±2.973e-08s)
Trimean of differences: 5.27500e-08s, 95% CI: 2.32500e-08s, 8.375000e-08s (±3.025e-08s)
Layperson explanation: Large confidence intervals detected, collecting more data necessary. Side channel leakage smaller than 2.904e-08s is possible
For detailed report see rsa2048_oaep_repeat/report.csv

I'd still say we could probably do better - the values are blinded, so while it's not clear if anything meaningful would be getting leaked a better mod-pow would probably drive things down further and we'd stop worrying about this.

thanks for sharing the results!
this: p-value: 0.008678135718454017 does make me squint, and in general I'd suggest collecting more data, even without this result, but it does show a significant improvement


Broadcast packet could not be received

Tested on centos7, the broadcast packet could not be received, and the packet capture found that the system did not receive the broadcast packet, and UDP port 67 was in the listening state.

已解决，需要关闭firewalld


Simple File Picker - Selecting a file without leading / prefills input undesirably

VSCode Version: Insiders (1.37.0)
OS Version: Linux

Steps to Reproduce:

Open the simple file picker
Clear the default path from the input
Wait a moment for the root files to be shown
Press on the down button twice
Notice the path in the input is prefixed by the first letter of your first selection

Does this issue occur when all extensions are disabled?: Yes

@diabolicle is this the native file picker. Can you post a video showing what you are seeing?

@alexr00 FYI

Nice bug, thank you for finding!


Proposal: Provide public access to a button's ripple

Bug, feature request, or proposal:
Proposal
What is the proposed behavior?
Public access to the MdRipple within a button, nav-list-item, etc
What is the use-case or motivation?
I'd like to programmatically trigger a button's ripple to call attention to it. Under feature discovery, there is discussion of using ripples to guide users through flows: "Ripples guide users through subsequent steps".
Currently, there is no good way (if any?) to access the button's ripple. I suppose I could create a new rippled component and position and mask it correctly, but that seems needlessly complex.

Thinking about a good way to expose the ripple instance.. Any ideas already?

Why not just a public @ViewChild(MdRipple) in button.ts?

Hm yeah. We might be able to just make that public. For most of the components like md-slide-toggle, md-checkbox and md-radio we already have a reference to the MdRipple directive.
Need to discuss this first with @jelbourn. Not sure if we should expose the underlying ripple instance.

The launch method on MdRipple doesn't exactly have an API that would make it easy to say something like button.ripple.launch(). If we were going to expose the instance, I'd want to have a simpler user-facing API.

Basically for components like the slide-toggle, radio etc. we provide a ripple config that will be used when calling slide-toggle.ripple.launch().
For buttons it will be a bit more weird because the ripples don't launch from the center.

I think I see the difficulty. With a normal button, if you just used launch() it would render from the top left of the viewport and only barely show up within the button's bounds.
It would seem ideal to be able to pass an override config through launch() that would merge with the preexisting config:
this.button.ripple.launch(0, 0, { centered: true });

Overall, I agree with @jelbourn that the api could/should be simplified. It isn't exactly clear how pageX, pageY, and centered all interact, and it doesn't seem like there's a good way to trigger a ripple from, say, the bottom left corner of a component.

@willshowell Exactly, the ripple would render from the top-left.
And regarding positioning, I personally think that such positioning stuff shouldn't be part of the ripple service. The service was designed to be very low-level since it is mostly used internal.
What I think would be a better way, is like a TypeScript mixin (e.g #3944) that will provide a custom launchRipple method on the button.
This mixin could be responsible for more API-friendly ways of launching ripples on a component.
Although I still don't think that we should provide APIs for bottom-left, bottom-right etc. positions.

Big fan of the mixins idea!


Add support for SR-IOV cni plugin

Do not merge before #508 on which this one depends.
Thinks which need additional work:

[ ] replace suid bit hack with proper propagation of rights for accessing pci devices by qemu (code for configfd already in sources, but even after passing it through tapmanager/vmwrapper - there is an access error)
[ ] RecreateContainerSideNetwork depends on possibility to look on interfaces in container namespace, but when one is passed to VM it's disconnected from host. Better way of that would be to serialize full csn to metadatastore and deserialize in during this recreate, so there would be no need to try to guess pci address from the sysfs
[ ] csn.Teardown rebinds interface kernel driver, but device is probably visible only on host and this func is called in container namespace. Also even on host it probably will have other mac address than our autogenerated (which is now used to find device), so instead of finding it using mac address it probably needs to be located on TapFDSource.Release level by pci address, moved to container namespace and at the end renamed using name expected by cni plugin.

This change is

Reviewed 5 of 5 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


Error when trying to use --http-cookie

When I try to pass any --http-cookie option, I get the following stack trace:
Traceback (most recent call last):
File "", line 6, in
File "main.py", line 128, in
File "main__livestreamer.py", line 9, in
File "livestreamer_cli\main.py", line 839, in main
File "livestreamer_cli\main.py", line 614, in setup_http_session
TypeError: 'NoneType' object is not iterable

Thanks for your report, this has been fixed by 243edf1b04d2e5a648b70564338a522543e4b2a2 and will be availabe in the next release soon.


[UI/UX] Selected project label

After selecting a project from the side-drawer, the title of the selected project is not shown anywhere in the app.
I propose that, we add that info somewhere in the app or change the UI to make it more intuitive (For e.g. Instead of opening a dialog when selecting "Select Project", we expand it and highlight the one selected)

How about showing the list of projects in a section in the left-side drawer (nav menu)? Then the active one can appear checked/selected.

SGTM!

..this could be similar to how Gmail Android displays labels: https://support.google.com/mail/thread/9052188). Instead of this we'd have something like:
PROJECTS
[icon] Project A
[icon] Project B
[gears] Join/leave projects
Wdyt?


🐛 DReps shouldn't be voting on Hard Fork Governance action in bootstrapping phase

Area
Voting Pillar
Domain
preview.gov.tools
Which wallet were you using?
No response
Context
Reference GA - https://preview.gov.tools/governance_actions/049ae5d612b2fa825655809133b023d60c7f8cac683c278cf95de1622e4592f3#0
DReps shouldn't be voting on this. If govtool is getting those numbers from always abstain/no confidence, this should probably be fixed
Steps to reproduce

Go to govtool
Go to the specific GA - https://preview.gov.tools/governance_actions/049ae5d612b2fa825655809133b023d60c7f8cac683c278cf95de1622e4592f3#0

Actual behavior

There are voting numbers associated with DReps

Expected behavior

There shouldnt be voting numbers associated with DReps

@Ryun1 Should these numbers be 0 or completely hidden DRep section?
CC @m-i-k-e

Probably best to ONLY show the group(s) that can vote on the action type within that protocol version

Better defined for all groups in #2316


Feature Request - Add the 2 Servers from Metasploitable 3 to the Detection Lab

Operating System Version: N/A
Provider (VirtualBox/VMWare): N/A
Vagrant Version: N/A
Packer Version: N/A
Is the issue reproducible or intermittent? N/A

Description of the issue:
As a detection lab I think it would be good to add some highly vulnerable systems/applications to the Lab so defenders can verify if they can detect exploitation of those systems/applications.
Given Metasploitable 3 also leverages vagrant and packer it appears it would be achievable.
https://github.com/rapid7/metasploitable3

Hey @forensic65x - I like the idea, but this would be better suited for a fork of DetectionLab. The addition of more VMs slows down an already somewhat slow build process and adds complexity, which makes the lab harder to maintain than it already is. I don't want to get in the business of supporting a VM that I had no hand in creating.

Understood.
Could you provide some guidance on what scripts in the
detectionlab/Vagrant/scripts should be run on an additional Windows VM so
it gets the caldera agent, added to the domain, logs to the WEF server,
etc?  I'd like our DetectionLab to have a couple more flavors of Windows
(XP, Win7, 32 and 64bit).
Same for a unix VM so its logging to the Logger/Splunk...
If not, no worries.
On Sun, Jul 22, 2018 at 1:08 AM Chris Long<EMAIL_ADDRESS>wrote:

Hey @forensic65x https://github.com/forensic65x - I like the idea, but
this would be better suited for a fork of DetectionLab. The addition of
more VMs slows down an already somewhat slow build process and adds
complexity, which makes the lab harder to maintain than it already is. I
don't want to get in the business of supporting a VM that I had no hand in
creating.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/clong/DetectionLab/issues/125#issuecomment-406843603,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIUb7suVnOGA4evm5h8_NVyisf1SlPiwks5uJBbHgaJpZM4VZwcL
.


update minishift/README.md

fix Kedge URL with protocol
add instructions to add binary to local/bin

Codecov Report

Merging #1815 into master will decrease coverage by 0.06%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1815      +/-   ##
==========================================
- Coverage   63.84%   63.77%   -0.07%
==========================================
  Files         128      128
  Lines       11874    11874
==========================================
- Hits         7581     7573       -8
- Misses       3611     3619       +8
  Partials      682      682

Impacted Files
Coverage Δ

remoteworkitem/jira.go
75% <0%> (-25%)
:arrow_down:

remoteworkitem/scheduler.go
53.65% <0%> (-7.32%)
:arrow_down:

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 1965821...805e5e6. Read the comment docs.

@pranavgore09 snapshot fabric8-wit image is available for testing.  docker pull docker.io/fabric8/fabric8-wit:SNAPSHOT-PR-1815-2


sassc syntax error on RAILS_ENV=production bundle exec rake assets:precompile due to a specific line in my CSS

After attempting RAILS_ENV=production bundle exec rake assets:precompile, i get the following error
SassC::SyntaxError: Error: Invalid CSS after "...ia screen\\0 and": expected "{", was "(max-width: 1024px)"
        on line 18866 of stdin
>> @media screen\0 and (max-width: 1024px) {

It looks like this has to do with screen\0..? Not sure exactly why, but it seems like only sassc compiler is noticing this as invalid, however, it came straight from a reputable bootstrap theme, and has always worked before dropping in sassc-rails.

It's taking issue with all of my CSS too, seems like the files aren't loading in the right order or something.  Incredibly frustrating to see it throw me syntax errors with valid, working CSS.

@alaarab @bjgaynor were you able to fix this?

Did anyone manage to resolve this?

Did anyone manage to resolve this? UP!

I do remember running into this issue when I was upgrading my rails app, but I don't remember what my solution was. I did not change my CSS at all, since the CSS belonged to a theme and I didn't want to do that. Looking back at my app, I see I commented out this gem completely from my Gemfile, and have gem "sass-rails", ">= 6" in my Gemfile, which is supposed to just be a wrapper for this Gem, so I'm not sure what made this start working for me. It might have been some other change I made that truly resolved this.

I already figured it out the issue. in rails 6 you have to pack everything in javacscript/packs/application.js so when you run rake assets:precompile there is no problem.

I am getting a similar error as well:
** Execute assets:precompile
rake aborted!
SassC::SyntaxError: Error: 1.75rem/add isn't a valid CSS value.
        on line 2746 of stdin
>> e%3c/svg%3e") #fff no-repeat center right 1.75rem/add(0.75em, 0.375rem) add(
   ------------------------------------------^
stdin:2746

Having a very hard time trying to figure out what's causing this.

This answer on SO worked for me:
https://stackoverflow.com/questions/70401077/rails-7-asset-pipeline-sasscsyntaxerror-with-tailwind/70665740#70665740
I put inside production.rb and deployment was fine, while retaining gem "sassc-rails" in my Gemfile though.

Add this to application.rb
config.assets.css_compressor = nil
Solved it. Thanks to: https://github.com/sass/sassc-rails/issues/131


Sklearn 1.2 version breaks patch_sklearn()

Describe the bug
new Sklearn version breaks monkeypatching for patch_sklearn()
To Reproduce
Steps to reproduce the behavior:

Setup:
pip install --upgrade scikit-learn
pip install scikit-learn-intelex

Call
from sklearnex import patch_sklearn
patch_sklearn()

Use '....'

See error

Expected behavior
Describe what your are expecting from steps above
Output/Screenshots
Traceback (most recent call last):
File "/workspaces/codespaces-jupyter/MLP_CLF.py", line 2, in
from sklearnex import patch_sklearn
File "/home/codespace/.python/current/lib/python3.10/site-packages/sklearnex/init.py", line 18, in
from .dispatcher import patch_sklearn
File "/home/codespace/.python/current/lib/python3.10/site-packages/sklearnex/dispatcher.py", line 22, in
from daal4py.sklearn._utils import daal_check_version, sklearn_check_version
File "/home/codespace/.python/current/lib/python3.10/site-packages/daal4py/sklearn/init.py", line 17, in
from .monkeypatch.dispatcher import enable as patch_sklearn
File "/home/codespace/.python/current/lib/python3.10/site-packages/daal4py/sklearn/monkeypatch/dispatcher.py", line 18, in
from ..neighbors import KNeighborsRegressor as KNeighborsRegressor_daal4py
File "/home/codespace/.python/current/lib/python3.10/site-packages/daal4py/sklearn/neighbors/init.py", line 18, in
from ._classification import KNeighborsClassifier
File "/home/codespace/.python/current/lib/python3.10/site-packages/daal4py/sklearn/neighbors/_classification.py", line 19, in
from ._base import NeighborsBase, KNeighborsMixin
File "/home/codespace/.python/current/lib/python3.10/site-packages/daal4py/sklearn/neighbors/_base.py", line 40, in
from sklearn.neighbors._base import _check_weights
ImportError: cannot import name '_check_weights' from 'sklearn.neighbors._base' (/home/codespace/.python/current/lib/python3.10/site-packages/sklearn/neighbors/_base.py)
Environment:

OS: Ubuntu 20.04.5 LTS
PY 3.10

This is fixed already in code - new deployment to PyPi would happen on next week

thank you for the swift reply


Sequencer

https://gitlab.com/GroGy/im-neo-sequencer

https://github.com/CedricGuillemet/ImGuizmo


Local development with GAE

Closes #1048 and #998, a step towards #843.

This looks good overall.  Just to confirm, we are getting rid of the  "open" because we now have a full template that is rendered on app engine, but the build for deployment still correctly misses out the  magic.

Correct. The build is now always the devsite-style, and the App Engine script adds the extra tags.


slicing passmanagers

following #3004, implement methods to slice PassManagers to only get a subset of passes:
pm = PassManager(...)

pm[1]
pm[1:3]

pm1[1:3] + pm2[4:6]  # be able to concatenate several passmanagers

I'm trying to implement this. However I need some guidance:
pm[..] should return a PassManager with subset of passes (rather than the subset of passes it self) correct?
because this way it would allow to carry conditions, options .. etc
also it will allow something like
pm[0:3].draw()
it will also allow
pm[..] + pm[..]
and
pm + pm[..]
to act in similar way.
the only downside would be that this won't work:
pm1[3] = pm2[1]

pm[..] should return a PassManager with subset of passes (rather than the subset of passes it self) correct?

Yes. It should. Currently, a PassManager does not fully emulate a container type. And I think it should though. A PassManager is a collection of pass sets (FlowController instances) that are saved in working_list list. That's the list that is important here.
"Wrap" the working_list. Let me know if that makes sense. We can discuss it with code.

That makes perfect sense. Thanks. Will report once I finish.

pending PR in #3209

closed via #3209


chore: confirm closews works

Fixes RVT-4453
Changes

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#1715  👈 (View in Graphite)
#1714
#1712
#1711
#1710
#1709
#1708
#1707
#1706
#1695
main

How to use the Graphite Merge Queue
Add the label merge-queue to this PR to add it to the merge queue.
You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has required the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.


"Unable to verify authorization request state." during the passport.authenticate()

When using the Auth0 strategy and in production mode (sameSite = none as well), I get the following:
"Unable to verify authorization request state." during the passport.authenticate()
I see that we added "state: true" as part of the strategy, and when I take that out I get
"Error: Scope "openid" is not allowed without Auth0Strategy state true"
This appears to work fine locally.

I’ll do some more investigation and report back.

I'm using medusa extender and modified main.ts with and it's still not working and getting the same error. I tried all combinations of saveUninitialized and resave as well.
    expressInstance.use(
        session({
            proxy: true,
            secret: process.env.COOKIE_SECRET,
            resave:false,
            saveUninitialized: true,
            cookie: {
                sameSite: false,
                secure: true,
                maxAge: 1000 * 60 * 60 * 48,
                httpOnly: false,
            }
        })
    );
     expressInstance.set('trust proxy', 1);
        ```

Opened a thread at Auth0 community forums.  I think we should hold off on releasing this feature until someone has got it working with cross-site cookies working.

In a production env, the sameSite is set to none, secure (cookie) is set to true. Since same site as to be none with secure cookie (all new browser expect that for security reason). And the trust is always set to 1. you can look into the medusa express loader to see those config.

Opened a thread at Auth0 community forums. I think we should hold off on releasing this feature until someone has got it working with cross-site cookies working.

Nice 👍 I ll wait to see what is the output. I was about to release, just done the build and see this issue before releasing 😂

yes, it doesn't work with sameSite = 'none' either.
Maybe you can test this with another app, but I can't get it to work.
When I check Auth0 logs I see a successful login, but passport.authenticate() in the router builder redirects to failureUrl with this message.

Or at the very least if someone gets it working we can provide some guidance in the docs.

@juanzgc any thought on that one?

Just saw this issue, taking a look and will respond once I have some sort of solution

@Arsenalist @juanzgc have you checked that guys https://github.com/auth0/passport-auth0/issues/70#issuecomment-435711912

@Arsenalist @juanzgc have you checked that guys auth0/passport-auth0#70 (comment)

What key under session would I set that token in?

Have you try to use it locally and set the NODE_ENV=production on startup to see if you get something different. It would mean running under https as well. If it is a proxy issue and testing locally does not provide the error then we can confirm it is a proxy issue if the remote provider us a proxy on front of nodejs. Does that make sense?

So I looked at it more and I finally was able to get this working, but I had to add the following to my main.ts:
    expressInstance.use(
        session({
            secret: process.env.COOKIE_SECRET,
            resave: true,
        })
    );
    ```

Once I added this, the message goes away. I think the root cause here was the cookie not being set, but this did it.

Might be worth checking if the same happen without the extender. In that case we might had a line in the doc no?

Might be worth checking if the same happen without the extender. In that case we might had a line in the doc no?

I can check, though I am pretty deep into extender at this point. Is there a way to skip using extender without removing it fro package.json?

Yes, you can run medusa develop directly and it will use the default entry file instead.

It doesn't work with just medusa develop (when NODE_ENV is set to production).
In my case I'm on a Netlify front-end and a VPS hosting the backend. There are no proxies at play here.

What is your domain? Is it a custom one or the provider one with a sub domain

It's a top-level domain. example.com. The app is located on api.example.com.

Ok so it is not one of the public suffix list

Can we release this?


Add lock_state_changed signal to CogitoDoor

Just adding and emitting a signal when the door's lock state is changed.
I used this in order to sync door locks in my Coop project, but it could be used to hook anything to a door being unlocked.

One tiny change could be to add a setter for is_locked, which handles emitting the signal whenever the state changes. This way no matter what causes the state to change (e.g. a lock_door() method is introduced later down the line, or someone manually sets the state somewhere else), the signal gets emitted.

One tiny change could be to add a setter for is_locked, which handles emitting the signal whenever the state changes. This way no matter what causes the state to change (e.g. a lock_door() method is introduced later down the line, or someone manually sets the state somewhere else), the signal gets emitted.
This would look something like:
is_locked: bool:
    set = _set_is_locked

# ...

func _set_is_locked(value: bool) -> void:
    is_locked = value
    lock_state_changed.emit(is_locked)

I'm still learning gdscript. Is defining the variable like that going to call the function whenever the variable is changed, regardless of how it is changed?
I wasn't aware of setters like this in gdscript.

Thanks for linking the docs.
I see value in a setter and getter, but it also begs the question if the same should be done for is_open.
Keep in mind if doing it for both it doesn't really increase functionality for games.
I propose instead that I write a simple lock_door function. This would actually increase functionality for games and cover all use cases for locks.

True, is_open could have one too. It's really just a way to ensure that something happens when the state changes, even if the state is changed in the "wrong" way (e.g. for whatever reason directly altering the variable instead of using a method in some script). This way if you also do end up having more methods altering the state and sending signals, you keep the code a bit more DRY.

The way you put DRY in all caps makes me think this is a programming
concept I haven't heard of, too. Lol
On Tue, Apr 23, 2024, 22:32 aronand @.***> wrote:

True, is_open could have one too. It's really just a way to ensure that
something happens when the state changes, even if the state is changed in
the "wrong" way (e.g. for whatever reason directly altering the variable
instead of using a method in some script). This way if you also do end up
having more methods altering the state and sending signals, you keep the
code a bit more DRY.
—
Reply to this email directly, view it on GitHub
https://github.com/Phazorknight/Cogito/pull/177#issuecomment-2074064957,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABJVOIZZVJ3CHQOGH26YI23Y647YVAVCNFSM6AAAAABGT5ZEZGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZUGA3DIOJVG4
.
You are receiving this because you authored the thread.Message ID:
@.***>

Haha, yeah, it is 😄 DRY = Don't Repeat Yourself

I think I'm going to leave this pull request as is.
@aronand I agree with the suggestions you are making, but in practice it's a little finnicky. I feel like keeping open_door, close_door, and unlock_door public and the is_open and is_locked variables "private" would be the proper way to do this.
However, the variables are used initially to set the state for the start of the scene so they aren't entirely "private"....
Trying to do it the other way, where I use setters and getters I run into a recursion problem. The interact function is already calling functions like open_door, close_door, and unlock_door. This could be rewritten to set the variable instead, but then there is the problem of passing the interactor to the open_door function.
I just don't feel like any solution I have come up with in practice is cleaner or better, there is always something still wrong with it. If someone else wants to improve this further, feel free.

Yeah the is_open and is_locked flags are something that are good to be publicly readable at least, as someone might want to check those in a script of their own.
I can have a go at a possible implementation during the week when I have the time, but I think it can also be turned into an issue of its own, especially as it's looking to be a larger refactor than just a small edit in logic in a single file.


fix: the interface does not prompt information when deleting a cluster with backup

Signed-off-by: liuying<EMAIL_ADDRESS>
What type of PR is this?
/kind bug

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #183
Special notes for reviewers:

Does this PR introduced a user-facing change?

Additional documentation, usage docs, etc.:

/lgtm
/approve


make  const ref proxy assignable to  ref proxy

I am currently rewriting these classes, we can close this kne.


Potential Fix for Issue #741 (Transform not giving expected results for similar data #741)

Some changes to fix the Transform issue #741

num_neighbours replaced by row_sum in init_graph_transform.
move_other now an optional argument in optimize_layout functions.
move_other=True in fit_transform code path.
Ran black on code.

Hello @jh83775! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file umap/__init__.py:

Line 14:5: E301 expected 1 blank line, found 0

In the file umap/umap_.py:

Line 2727:89: E501 line too long (94 > 88 characters)
Line 2728:89: E501 line too long (94 > 88 characters)
Line 2742:89: E501 line too long (101 > 88 characters)

Thank you!


allows for non-editable build

Actually, this is enough for the package, but not data and config files, let me update them as well

Hey thanks! Is this still working in progress?

Yes. It actually requires much more work than I thought, because many weights loading and import operations relies on the editable install - and not only limap, but submodules as well...


SPFX WebPart exposed as teams app not visible in Teams app and teams web

Target SharePoint environment
SharePoint Online
What SharePoint development model, framework, SDK or API is this about?
💥 SharePoint Framework
Developer environment
Windows
What browser(s) / client(s) have you tested

[ ] 💥 Internet Explorer
[X] 💥 Microsoft Edge
[ ] 💥 Google Chrome
[ ] 💥 FireFox
[ ] 💥 Safari
[ ] mobile (iOS/iPadOS)
[ ] mobile (Android)
[ ] not applicable
[ ] other (enter in the "Additional environment details" area below)

Additional environment details

browser version= latest
SPFx version=1.20.0
Node.js version=18.20.0
etc

Describe the bug / error
Greetings,
I'm trying to work on a new Spfx tab app to be deployed on web team and then on our teams app,
I followed this tutorial tutorial to the letter
as well as the video version which you'll find here.
I verified that the webpart contains the TeamsPersonalApp and TeamsTab parameters.
Upon adding the solution to app store

And verifying that it exists in my teams app store (i'm using the tenant admin account by the way)

PS: finally the app is open to all users.
Howerver the app is not found when i search for it in app store in team

Any Help and guidance is highly valued.
My regard,
Steps to reproduce
1.There is no actual steps to follow just the Microsoft provided tutorial
Expected behavior
The app should be available for display in Teams web.

I am experiencing the very same issue. addiationally after SyncToTeams from SharePoint the app shows as "Blocked" for about an hour in the teams app store., but that goes away on its own - yet it is not visible in any teams client, even if using the web browser version and clearing all data


UMOD/OXIDE Develop Branch for Linux

Please, could you change the Oxide Version to the Developing Branch as this is now the Linux Branch for oxide.
If it's not changed then we cannot use Oxide on our Linux Servers (Or Docker Containers)

Would love to see this as well.  I am unable to use this docker with oxide enabled.

Workaround for me as Unraid User:
Login with Shell:
apt-get update
apt-get install nano
nano start.sh
Change line 336
OXIDE_URL=$(curl -sL https://api.github.com/repos/OxideMod/Oxide.Rust/releases/latest | grep browser_download_url |  cut -d '"' -f 4)
to
OXIDE_URL=$(curl -sL https://api.github.com/repos/OxideMod/Oxide.Rust/releases/latest | grep browser_download_url | grep linux | cut -d '"' -f 4)
maybe helps someone


flutter drive -d chrome error message when not running chromedriver should be more helpful

ianh@burmese:~/dev/flutter/examples/hello_world$ flutter drive -d chrome test_driver/smoke_web_engine.dart
Downloading Web SDK...                                           2,166ms
Running "flutter pub get" in hello_world...                        830ms
Launching test_driver/smoke_web_engine.dart on Chrome in debug mode...
Waiting for connection from debug service on Chrome...             18.2s
Debug service listening on ws://<IP_ADDRESS>:42343/E5svjfQ99qs=/ws

💪 Running with sound null safety 💪
Application finished.
Unable to start WebDriver Session for Flutter for Web testing.
Make sure you have the correct WebDriver Server running at 4444.
Make sure the WebDriver Server matches option --browser-name.
SocketException: OS Error: Connection refused, errno = 111, address = localhost, port = 48318
ianh@burmese:~/dev/flutter/examples/hello_world$

The problem here, at least according to the public documentation at https://flutter.dev/docs/testing/integration-tests#running-in-a-browser and our team-internal documentation at https://github.com/flutter/flutter/wiki/Running-Flutter-Driver-tests-with-Web, is that I'm not running chromedriver, but the error messages above don't mention that at all.

@Hixie Hi, I'd like to start working on this issue but I have a couple of clarifying questions. After looking through the linked documentation, it seems that different browsers require different drivers and have different installation processes. I believe the error message is handling all of these different browsers by providing the more generic error about running the correct WebDriver.
Does it make sense to provide extra information about the chromedriver specifically? If so, should we only do so when the browser option is chrome?
If not, should we add a unique message for each browser that provides more insight on how to run its WebDriver, or could we just provide a link to the relevant documentation?
I would personally think that a link to the documentation would be best, since it takes advantage of the existing documentation, it's the most generic, and it's likely the most helpful, since any error about the WebDriver is likely to lead people to the documentation anyways. Let me know what you think!

Re-checking this on the latest Flutter stable 3.19.5, I see the current message seems to be improved as it's mentioning chromedriver and also gives instruction via URL:
Unable to start a WebDriver session for web testing.
Make sure you have the correct WebDriver server (e.g. chromedriver) running at 4444.
For instructions on how to obtain and run a WebDriver server, see:
https://flutter.dev/docs/testing/integration-tests#running-in-a-browser

@Hixie Do you think the output is better now?

Ah, just noticed the linked PR above. Closing the issue as fixed.


Assesment of BLS validations in ARSBlockRelay

The idea is to assess a Block Relay smart contract which implements BLS validations, using the bn256 library and set the Active Reputation Set as the voting committee.
Add tests.

Moved to https://github.com/witnet/witnet-ethereum-block-relay/issues/16


how to get the index of images in gallery?

@lukasz-galka i have a ngx-gallery and a button and i want to print the images that is previewing in the array of images when i click the button. how can i get the index of previewing images?

there is an event previewChanged https://github.com/lukasz-galka/ngx-gallery#events

like other events, example here https://github.com/lukasz-galka/ngx-gallery/issues/50#issuecomment-335866838

@lukasz-galka
I can detect if preview changes but how can get index of current image?


feat(15): Expose Custom table to have ability to change table behaviour

@varmakarthik12
Thank you for the PR.
If you could fix the Linter's suggestions and write unit tests, I will merge this PR.

@varmakarthik12 Thank you for the PR. If you could fix the Linter's suggestions and write unit tests, I will merge this PR.

@nao1215 , Thanks for reviewing,  This is now taken care.

@varmakarthik12
Thank you for your response.
I merge your code now.


Support multiple scope

Support a part of #35, multiple scopes with all and any combinator.
As:
from fastapi_cloudauth import Operator

@app.get("/access-all/")
def secure_access_and(scope=Depends(auth.scope(["role_admin", "super_admin"]))):
    return f"Hello {scope}"

@app.get("/access-any/")
def secure_access_or(scope=Depends(auth.scope(["role_admin", "super_admin"], op=Operator._any))):
    return f"Hello {scope}"

This is exactly what I need, could you add some documentation to the readme for how it is used?
Specifically I don't understand what the auth object is and where I can get it from.
Thank you!


Adding utils for working with image patches in Torch

Adds a fiftyone.utils.torch.TorchImagePatchesDataset dataset that emits tensors of patches extracted from images defined by sets of Detections associated with the images.
A test was added to tests/misc/torch_tests.py that verifies the functionality, although it must be run manually.
Also includes two other minor things:

makes sample_parser arg optional for methods like Dataset.ingest_images(), where the typical case is to directly pass in  images (for which the default ImageSampleParser works just fine)
Allows Polyine.to_detection() and Detection.to_polyline() to ignore instance masks

LGTM


Omit sys.version_info and sys.platform checks from ternary rule

Resolves #1753.

I appreciate this fix a lot, thank you!


Beware of quotes

The following is simply a comment on the documentation.
If you place quotes around the 'name' elements in a record (in this case, 'Flavor' and 'Quantity' you will receive an error (probably 'expecting indent' or 'expecting colon')
// the following example will not work
Collect( IceCream, { "Flavor": "Pistachio", "Quantity": 40 })

// leaving off the quotes on the 'name' element is acceptable, however you must keep them on the 'value' element (such as 'Pistachio')
Collect( IceCream, { Flavor: "Pistachio", Quantity: 40 })

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: d9c49101-d089-7743-582f-d44973632751
Version Independent ID: ec080088-0d3f-f9fe-7090-c140bacfc07b
Content: Collect, Clear, and ClearCollect functions - PowerApps
Content Source: powerapps-docs/maker/canvas-apps/functions/function-clear-collect-clearcollect.md
Service: powerapps
GitHub Login: @gregli-msft
Microsoft Alias: gregli

@gregli-msft I can take a first shot at this.

@kuhlaid Thanks for your feedback! This topic shows quotation marks around values but not field/column names. Should we state explicitly that app makers should, when creating formulas, follow the same syntax as the examples?

It might help to explain the required syntax for name/value pairs and note
that the 'name' value should not contain quotes.  Quotes caused me problems
until I realized they were not needed.
Cheers
On Wed, Aug 22, 2018, 5:38 PM Anne Frances Owen<EMAIL_ADDRESS>wrote:

@kuhlaid https://github.com/kuhlaid Thanks for your feedback! This
topic shows quotation marks around values but not field/column names.
Should we state explicitly that app makers should, when creating formulas,
follow the same syntax as the examples?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/powerapps-docs/issues/40#issuecomment-415189634,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AnoGRWColtYmW336AOv_3ijL4-keAlJXks5uTc9QgaJpZM4WIQHD
.

Yes, I am familiar with JSON formatting and did not run across any mention
of the PowerApps record formatting.  Is this mentioned in another document?
many thanks
On Thu, Aug 23, 2018 at 10:19 AM Greg Lindhorst<EMAIL_ADDRESS>wrote:

Hey @kuhlaid https://github.com/kuhlaid, thanks for the feedback. I'm
curious, are you coming from a JSON background? I'm trying to understand
what misled you to believe that quotes were needed or if that was something
you just naturally thought was appropriate.
Our syntax for records is similar to JSON, but as you found, we don't
quote our names. That was a decision made long ago in the belief that it
was simpler to use (which I believe it is).
Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/powerapps-docs/issues/40#issuecomment-415431401,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AnoGRfIhtyFZyZbGliHGgi_ewcSWKmQBks5uTroOgaJpZM4WIQHD
.

--
w. Patrick Gale http://pgale.web.unc.edu/
Web Applications Handyman & Data Librarian

Yes, it is described in https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/working-with-tables.  We don't go out of our way to explain that quotes are not required, especially for those coming from a JSON background, and what makes things worse is that they are required in some contexts (RenameColumns).  We could be clearer overall.  We should add a note about quotes not being needed in the tables article.  There is already a link to the article at the top of the Collect function article.  Does that seem reasonable?

JSON normally accepts and expects quotes around the name element in the
instances I use it.  As long as PowerApps does not accept double quotes in
the name element there should be a sentence in the docs telling users to
leave them off.  I spent a good amount of time trying to debug code that
wrapped the name element in double quotes and kept receiving unhelpful
errors about expected indent and expected colon.  I'm just making a
suggestion from the user perspective.
In the section of 'inline syntax' on
https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/working-with-tables#record-scope
,
where it gives an example of record syntax:
{ Name: "Chocolate", Price: 3.95, 'Quantity on Hand': 12, 'Quantity on
Order': 10 }
After that, add a side note saying "Double quotes should not be used on
column names." Then either show an example or not.
cheers
On Thu, Aug 23, 2018 at 11:19 AM Greg Lindhorst<EMAIL_ADDRESS>wrote:

Yes, it is described in
https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/working-with-tables.
We don't go out of our way to explain that quotes are not required,
especially for those coming from a JSON background, and what makes things
worse is that they are required in some contexts (RenameColumns). We could
be clearer overall. We should add a note about quotes not being needed in
the tables article. There is already a link to the article at the top of
the Collect function article. Does that seem reasonable?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/powerapps-docs/issues/40#issuecomment-415456333,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AnoGRds50_x1eeSd6VxxweQR_AAxsl6Qks5uTsf6gaJpZM4WIQHD
.

--
w. Patrick Gale http://pgale.web.unc.edu/
Web Applications Handyman & Data Librarian

@kuhlaid Based on your feedback, we've updated the topic about working with tables. Cheers!
cc: @gregli-msft


Using CoOP for my own dataset

Hello!
As described in readme, CoOP is used for valid datasets in CoOp/configs/datasets/. If I want to try CoOP for my own datasets, How can I do?
Looking forward to your reply!
Thanks

follow a dataset in CoOp/datasets to write your dataset code (please see the code for more details)


what is the FIX for warning: "warning: possible EventEmitter memory leak detected. 51 open listeners added. Use emitter.setMaxListeners() to increase limit."

Hi, I would to know howto fix the warning: warning: possible EventEmitter memory leak detected. 51 open listeners added. Use emitter.setMaxListeners() to increase limit.
I seen that there are similar closed issues of it, but without real solutions.
if you see here (http://www.jongleberry.com/understanding-possible-eventemitter-leaks.html),
seems removeListeners is being missing
#117
Best Regards.

@eriknyk please provide code example that reproduces this issue

I will provide you the code soon thanks.

Running into this too, I am not sure, but I think it happens when there are too many queries executed, when mongoskin returned promise, but have not connected to database yet.
I usually do something like this:
var db = mongo.db(dbName, dbOptions);
db._emitter.setMaxListeners(0);

@ar2rsawseen

but have not connected to database yet

this is why,because if mongoskin has not connected to the database, it will register once('open') for the query to do queries when db connected


Bug: Golden Aercloud instantly kills the player

What happened?
Touching Golden Aercloud will shoot you down to the ground at a fatal speed, rather than shooting you upwards into the air  - I see this having potential being a feature as a new variant of Aercloud, but obviously, the Golden Aercloud is meant to launch you upwards into the air

Version
1.5.0 (Latest)
Fabric API Version
No response
Trinkets Version
No response
Relevant log output
No response
Other mods
No response
Additional Information
No response

The blue aercloud launches you into the air


Bump go version in alpine image to 1.23.2

What does this PR do?
Bumps go version in alpine image to 1.23.2.
Motivation
Address vulnerabilities CVE-2024-34156 & CVE-2024-34158.
Additional Notes
Related to https://github.com/DataDog/datadog-lambda-extension/pull/425
How to test the change?
Build serverless-init locally and run trivy image <image name> to confirm vulnerabilities are addressed.

Maybe fix the typo too? :shipit:


[automation] Update go release version 1.18.8

What
Bump go release version with the latest release.
Further details
See changelog for 1.18.8
Automatically generated from https://apm-ci.elastic.co/job/apm-shared/job/bump-go-release-version-pipeline/

:green_heart: Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

Start Time: 2022-11-07T04:05:15.700+0000

Duration: 10 min 55 sec

Test stats :test_tube:

Test
Results

Failed
0

Passed
176

Skipped
3

Total
179

:robot: GitHub comments
Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

/test : Re-trigger the build.


Validation of fields is nearly non-existent

This works and it shouldn't (look at the protocol)
apiVersion: score.dev/v1b1
metadata:
  name: frontend
containers:
  frontend:
    image: nginx:alpine
service:
  ports:
    www:
      port: 80
      protocol: Godzilla-growls-angry
      targetPort: 80

Translates with score-helm to:
containers:
  frontend:
    image:
      name: nginx:alpine
service:
  ports:
    - name: www
      port: 80
      protocol: Godzilla-growls-angry
      targetPort: 80
  type: ClusterIP

This also "works"
apiVersion: score.dev/v1b1
metadata:
  name: frontend
container-with-massive-angry-typo:
  frontend:
    image: nginx:alpine
service:
  ports:
    www:
      port: 80
      protocol: Godzilla-growls-angry
      targetPort: 80

Outputs this:
containers: {}
service:
  ports:
    - name: www
      port: 80
      protocol: Godzilla-growls-angry
      targetPort: 80
  type: ClusterIP

And it doesn't error at all, there is no validation as it exists with 0 status

In the first section, you specified an invalid protocol for the port.  In the second section, you used an incorrect field name for the container, which caused it to be ignored.
Try this for the first:
apiVersion: score.dev/v1b1 metadata:   name: frontend containers:   frontend:     image: nginx:alpine service:   ports:     www:       port: 80       protocol: TCP  # Update the protocol to a valid value, such as TCP       targetPort: 80
And this for the helm-part:
apiVersion: score.dev/v1b1 metadata:   name: frontend containers:  # Update the field name to the correct name, which is "containers"   frontend:     image: nginx:alpine service:   ports:     www:       port: 80       protocol: TCP       targetPort: 80

In the first section, you specified an invalid protocol for the port. In the second section, you used an incorrect field name for the container, which caused it to be ignored.

I think that's exactly @fernando-villalba's  point: these errors should be automatically detected by Score implementations to help with troubleshooting.

Duplicate of https://github.com/score-spec/spec/issues/6


[Overlay] Value too large for defined data type

After upgrade my coreos to 618, docker has changed the underlying filesystem from btrfs to extfs + overlay. Which eventually causes it fails to write any files large than 2.5GB in the containers.
Any error code 27 and message "Value too large for defined data type" will be thrown if the above operation happens.
A quick and dirty workaround is to copy the large file from readonly layer to writable layer and make write operation against the new file.
Below is my os environment:
$ docker info
Containers: 1
Images: 46
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Kernel Version: 3.19.0
Operating System: CoreOS 618.0.0
CPUs: 24
Total Memory: 126 GiB
Name: cnpvg50820393.pvgl.sap.corp
ID: CGDX:RF6J:OKCI:32FL:I3TS:AXQA:GVEQ:7IVJ:HDV7:DAU6:BBXH:XHX6

@stainboy Please keep in mind that Docker didn't decide on its own to use overlay, it was told to use overlay. How much free disk space have you got? Can you provide an exact sequence of steps to follow to reproduce this, please?

@unclejack Thanks for the quick responding.

can you guide me how to change the underlying fs back to btrfs?
here is the repro steps,

a. vi Dockerfile

FROM debian
RUN dd if=/dev/zero of=/home/dummy.bin bs=1 count=0 seek=3G
CMD echo 'foo' >> /home/dummy.bin

b. docker build .
c. docker run the newly created image
RESULT

docker build .
Sending build context to Docker daemon 2.048 kB
Sending build context to Docker daemon
Step 0 : FROM debian
---> c9fa20ecce88
Step 1 : RUN dd if=/dev/zero of=/home/dummy.bin bs=1 count=0 seek=3G
---> Running in 63e65b5f648f
0+0 records in
0+0 records out
0 bytes (0 B) copied, 1.898e-05 s, 0.0 kB/s
---> be6d49e2ecf7
Removing intermediate container 63e65b5f648f
Step 2 : CMD echo 'foo' >> /home/dummy.bin
---> Running in 8fc172955c0d
---> d90471f6dabb
Removing intermediate container 8fc172955c0d
Successfully built d90471f6dabb
docker run d90471f6dabb
/bin/sh: 1: cannot create /home/dummy.bin: Value too large for defined data type

@stainboy Thanks for providing the steps to reproduce the problem. No, I can't help you switch it back because that's how CoreOS set things up. You should ask your distribution vendor for help with a temporary workaround.
The potential Docker bug will be investigated by the Docker project.

@unclejack Thanks for the information. I will temporary reinstall the old coreos distribution and keep an eye on this issue.

i think that this is not a coreos or overlayfs problem, but a problem with the /bin/sh in debian, which is 'dash'.
see http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Value-too-large-for-defined-data-type

it seems that this does work on coreos w/ btrfs driver for docker, but not on coreos w/ overlayfs driver. quite strange :/

True, it works fine w/ btrfs. However, unlike what you said in the previous session, this is a generic issue that happens on all kinds of images.
Actually, in my case, I have created a kvm base image and put a 4GB size of win8.img into it. Every time I create a new container, kvm crash against overlay fs.

Upgrade to kernel 4.2, Docker 1.8.2 then testing again.

The issue still exists on the latest coreos 815.0.0 (kernel 4.2, docker 1.8.2)
Repro steps:
# show current path
pwd
# create dockerfile
cat > Dockerfile << EOF
FROM debian:jessie
RUN dd if=/dev/zero of=/tmp/dummy bs=1 count=0 seek=3G
CMD echo 'foo' >> /tmp/dummy
EOF
# build
docker build -t issue:11700 .
# test
docker run --rm issue:11700
# show version
uname -r
cat /etc/os-release
docker version

Output:
core@yy ~/repo/issue-11700 $ # show current path
core@yy ~/repo/issue-11700 $ pwd
/home/core/repo/issue-11700
core@yy ~/repo/issue-11700 $ # create dockerfile
core@yy ~/repo/issue-11700 $ cat > Dockerfile << EOF
> FROM debian:jessie
> RUN dd if=/dev/zero of=/tmp/dummy bs=1 count=0 seek=3G
> CMD echo 'foo' >> /tmp/dummy
> EOF
core@yy ~/repo/issue-11700 $ # build
core@yy ~/repo/issue-11700 $ docker build -t issue:11700 .
# test
docker run --rm issue:11700
Sending build context to Docker daemon 2.048 kB
Step 0 : FROM debian:jessie
 ---> 8c00acfb0175
Step 1 : RUN dd if=/dev/zero of=/tmp/dummy bs=1 count=0 seek=3G
 ---> Running in 3c95fbf7fc28
0+0 records in
0+0 records out
0 bytes (0 B) copied, 2.9604e-05 s, 0.0 kB/s
 ---> 95133dbfe46c
Removing intermediate container 3c95fbf7fc28
Step 2 : CMD echo 'foo' >> /tmp/dummy
 ---> Running in d7d264a44a19
 ---> 9ea7daa1326b
Removing intermediate container d7d264a44a19
Successfully built 9ea7daa1326b
core@yy ~/repo/issue-11700 $ # test
core@yy ~/repo/issue-11700 $ docker run --rm issue:11700
/bin/sh: 1: cannot create /tmp/dummy: Value too large for defined data type
core@yy ~/repo/issue-11700 $ uname -r
4.2.0-coreos-r1
core@yy ~/repo/issue-11700 $ cat /etc/os-release
NAME=CoreOS
ID=coreos
VERSION=815.0.0
VERSION_ID=815.0.0
BUILD_ID=
PRETTY_NAME="CoreOS 815.0.0"
ANSI_COLOR="1;32"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://github.com/coreos/bugs/issues"
core@yy ~/repo/issue-11700 $ docker version
Client:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   fae4436-dirty
 Built:        Thu Sep 24 08:01:15 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   fae4436-dirty
 Built:        Thu Sep 24 08:01:15 UTC 2015
 OS/Arch:      linux/amd64

This works on kernel 4.3.0

I tried both debian:jessie and busybox base images with 4.3.0 kernel. Going to close for now. Feel free to reopen if you still see it with newer kernels.


Doesn't change my status

Not sure what I'm doing wrong, but I'm using Visual Studio 2022 and have the 2022 extension installed, but my status isn't changing in discord.

Try to find the answer in issue #12. There was a similar problem that was solved by restarting/reinstalling the discord

@xuanhuongtrinh76
Did anything help from that issue?


Screenshot broken at Framework 13 page

https://docs.projectbluefin.io/framework-13

Got it, thanks!


Table row borders

The table row borders don't extend in instances where we have an empty cell. This is the most recent example /policy-compliance/enforcement/petitions/. This page is probably going to disappear soon though and I can't think of the previous pages where we've seen this occur. It is occurring on other pages though, so still think it's worth resolving.

Ugh, there isn't a way to do it with css alone. We'll have to create the empty td cells somehow to get the borders to show.

Low priority because yes it's annoying but it's not impeding usage of the page.

What's an example page showing this? I don't see it on /policy-compliance/enforcement/petitions/

No longer true.


With multiple tags for a scenario the previous tags are being overwritten

Expected behavior
If there are multiple tags then it should get appended to the list
Actual behavior
It is getting overwritten
Steps to reproduce

Create a spec

Specification Heading
=====================
tags:top

* something1

c
-----------------------------
tags:scenario3 ppp a b c d e f g h i j k l m n o p q r s t u v w x y z

* something
tags:b

run the spec
The tag associated with c is only b

Gauge version
Gauge version: 0.4.1.nightly-2016-05-18

Plugins
-------
html-report (2.1.1.nightly-2016-05-19)
java (0.4.1.nightly-2016-05-17)

Ideally, tags should be defined only once in a scenario. So if it's defined more than once, we should throw a parse error.

Fix should be available in nightly >= 03.06.2016


[to be closed in favor of #322] New Color UI and ability to edit HSL values of variants

closed in favor of #322


Nullable IgnitionRenderer

The spiral-packages/ignition-bridge dependency is in the require-dev section. Installing dependencies with the --no-dev flag will result in an error when starting the application.
ExceptionHandlerInterface was replaced with ExceptionHandler. ExceptionHandlerInterface does not have addReporter and addRenderer methods.

We got rid of Ignition


Dev

Codecov Report

Merging #10 into master will decrease coverage by 5.97%.
The diff coverage is 83.33%.

@@            Coverage Diff             @@
##           master      #10      +/-   ##
==========================================
- Coverage     100%   94.02%   -5.98%
==========================================
  Files           2        2
  Lines          62       67       +5
==========================================
+ Hits           62       63       +1
- Misses          0        4       +4

Impacted Files
Coverage Δ

sqema/sqema.py
93.44% <83.33%> (-6.56%)
:arrow_down:

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 d7cf6f3...4a78c95. Read the comment docs.

Codecov Report

Merging #10 into master will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master       #10   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            2         2
  Lines           62        69    +7
=========================================
+ Hits            62        69    +7

Impacted Files
Coverage Δ

sqema/sqema.py
100.00% <100.00%> (ø)

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 f231f08...23a873d. Read the comment docs.


Create informal Level 1 archive

As an IMPROVER developer I want a Level 1 archive with data in a nice format so that I can run case studies
Related issues: #33
Acceptance criteria:

Write some code to combine StaGE level 1 data over ensemble members and slice over times
Create a feature branch of the suite to run this and add push-to-archive capability
Create archive for February to May 2017

This ticket meets the acceptance criteria and is ready to close.
TODO: add some info to the developer guide about where is the archive and how to use it.