Application creation and deletion throws a null pointer exception on wso2-ob-am-2.1.0

Application creation and deletion throws a null pointer exception
TID: [-1234] [] [2018-03-12 12:32:34,915] ERROR {JAGGERY.site.blocks.application.application-add.ajax.application-add:jag} -  java.lang.NullPointerException: null {JAGGERY.site.blocks.application.application-add.ajax.application-add:jag}
steps
1.login as a user with subscriber permission
2.create an application or attempt to delete an application
Note: the UI shows an alert with a null message. The deletion is not working
exception
TID: [-1234] [] [2018-03-12 12:33:04,462] ERROR {JAGGERY.site.blocks.application.application-remove.ajax.application-remove:jag} -  java.lang.NullPointerException: null {JAGGERY.site.blocks.application.application-remove.ajax.application-remove:jag}

this was an error in workflow-xml


Code & data release

Any plan for releasing data and code?

别又是PPT秀肌肉吧

shit~~~~

阿里 ，你懂的😏

bo liefeng, you know it.


Picking multiple large images crashes app

Hello, I'm using this plugin in my application and when I pick multiple large images such as 44 MB + 25+MB etc. from photo gallery and the application crashes.
The stacktrace for the crash is attached herewith if that could help.
IOS-227-iYQrsSvAorjVkBERw_k0-callstack.txt

This may not be a permanent solution but the multi-image picker can be a heavy handed on memory when the post-image processing options are enabled. I use these options for smallest memory overhead
// Get photos from library/gallery List<MediaFile> ChosenLibraryPhotos = await CrossMedia.Current.PickPhotosAsync(new PickMediaOptions {     RotateImage = false,     PhotoSize = PhotoSize.Full,     CompressionQuality = 100 })

Thanks for the solution @MatthewKapteyn but it is not working

Nuts. I took a closer look at the stacktrace and it's running into memory problems as soon as it tries to read the selected image into memory.
At this point, there's two forks of this plugin that use drastically different picker controllers that might be more memory friendly and cause less problems for you.
https://github.com/bpater-tp/MediaPlugin
Replaces the ELC controller completely with GMImagePicker
https://github.com/matthewkapteyn/MediaPlugin
Uses ELC Controller for iOS 13 and below, PHPicker for iOS 14 and up.


gadgets: Optimize support for optional big fields

Some Gadgets support optional big fields, like cwd on the trace_exec gadget which is 4096 bytes long. The current support for these kind of fields is sub-optimal as we always send the full event when the field is disabled, it means, for each event we transfer a lot of bytes that aren't used for anything.
The scope of this issue is to implement a way to support these optional big fields in an optimal way.
Ideas
type-length-value (TLV)
The TLV encoding is very common in networking applications. We could support encode the optional fields by using this:
struct event {
	// all fixed fields
	gadget_timestamp timestamp_raw;
	gadget_mntns_id mntns_id;
};

// Add tlv fields
// TODO: support type: string and byte
GADGET_TLV_FIELD(event, cwd, 1) // 1 is the id
GADGET_TLV_FIELD(event, args, 2) // 2 is the id

int foo() {
	int tlv_size = 50; // make some calculations here for this
	int total_size = sizeof(struct event) + tlv_size;

	struct event *event = gadget_allocate_event(total_size);

	char *cwd = get_cwd();
	gadget_set_encode_tlv(event, cwd, strlen(cwd), 1);

	char *args = get_args();
	gadget_set_encode_tlv(event, args, strlen(args), 2);

	gadget_submit_event(event, total_size);

	return 0;
}

Multiple events
Another option is send optional fields in different "packets" from the eBPF program:
struct event {
	// all fixed fields
	gadget_timestamp timestamp_raw;
	gadget_mntns_id mntns_id;
};

int foo() {
	// Allocate and send event
	struct event *event = gadget_allocate_event(total_size);
	gadget_submit_event(event, sizeof (*event));

	// send optional fields
	char *cwd = get_cwd();
	gadget_submit_event(cwd, strlen(cwd));

	char *args = get_args();
	gadget_submit_event(args, strlen(args));

	return 0;
}

I have the gut feeling that the TLV idea is easier to implement; however I wanted to show both of them for the discussion.

I also think TLV would be cleaner, if it can be made to work. I don't know if the bpf verifier could cause problems in some cases with size calculations.


add hydratable: true to solid

this is a follow up for a issue I noticed when using this package https://discord.com/channels/722131463138705510/1299231319884169216/1299231319884169216

closing in favor of #12 and #13


Test against InfluxDB nightly builds

Actually we test only the current version, we should also run the testsuite against InfluxDB nightly builds

A new inspection was created.


Add author field to the project and mirror it in study/dataset

DataCite properties for a Contributor (which can be an author)

Full name
familyName
givenName
nameIdentifier (e.g., an ORCID value)
nameIdentifierScheme (e.g., saying that this identifier is an orcid)
schemeURI (e.g., http://orcid.org)
affiliation (free text)

@NRayya From the above properties, can you please identify the fields which are required/mandatory?

Full name
nameIdentifierScheme if the nameIdentifier was provided

It is still not mirrored in the study

Close this issue if this works for the projects and create one for the study. We will pick this up after obtaining some feedback from our users.


RKE - Config Options Documentation Issues

Summary:

There is differences between Cases and wording on the Secrets-Encryption RKE page https://rancher.com/docs/rke/latest/en/config-options/secrets-encryption/#example-using-custom-encryption-configuration-with-user-provided-32-byte-random-key
Details:

See line 5 of the code snippet it says “api_version” the rest of the documentation and the input i’d expect is “apiVersion” Also the document changes between lower and upper case R for "Resources" It would be good to clarify which should be used.

@Sheldons92, we are still testing using upper and lowercase "resources" to give you the best information on how to proceed; I'll update you once we have a verdict.


PR: Ensure correct version is detected with pip

Checklist

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

Building without setuptools_scm produces a package with version 0.0.0 when checking with pip

@conda-forge-admin, please rerender


Make the effect of silences more obvious in realtime

Currently, you add a silence, and then you have to wait for the next group interval to see what actually got silenced.
Ideally, there is a "preview" button to check what alerts would be silenced if I created the silence right now. Then, the current alerts who will be properly silenced on the next group evaluation, should be marked as silenced right after creating the silence.
I guess that means an "out of band" extra run of the just created silence (with the same to be done for the "preview").

For adding a silence this requires a pass over the existing alerts, so far so O(N).
When deleting silence we now have to check the alerts silenced by the deleted silence and whether they are now silenced by another one – O(NM). Unless we constantly keep state about all silences affecting an alert.
All possible in general. Doing it in a clean and scalable way is more difficult. Needs some careful consideration. We'll want to avoid persisting that information at the cost of recomputing it all on each reload. We always have to keep in mind that every feature at some point must be working in a distributed setup.

I think even in a large organization the total number of silences and active alerts will be on the order of thousands, not millions. I don't think O(N) is an issue until long after N becomes too big to display in a browser. If need be, just stop after the few thousand, it's not going to be helpful for a preview anymore.
If deletion becomes a problem, it can move into the background again.
I don't think we need to be afraid of O(N) just on principle.

I'd expect silences to be on the order of thousands, but alerts could easily hit the millions.

It's a totally reasonable feature and possible I would say. Just saying we have to be careful to not implement features (in a way) that cannot a scale.

Since this is a pure display issue, it can be done best-effort (i.e. don't do it if the alertmanager is too busy already).
WRT O(NM): Fundamentally, we only need to do what we would do every 5min anyway, just out of band and only affecting display? Or am I misunderstanding something?

:+1: kind of confusing. Until we settled on a solution, what about showing a warning after creating a silence like "It can take up to xxx seconds until the silence becomes visible in the UI"?


Does not work with changed project root

When I change the root config the composables are not resolved at all

hello， @wvffle, Because I only made the directory under src，Maybe it can have a more reasonable path processing, but I'm doing other work at present. If you have good suggestions, welcome PR

hello, @wvffle the root option is supported now，you can look README_EN.md#root


Possible to use location outside of your repo?

Something like this?
app.use(favicon('https://d1ir1l1v07ijd0.cloudfront.net/img/ico/favicon.ico'));

So the quest is, possible to use something that the Node.js fs module cannot read? It is, since this module will also accept a Buffer, so you can write code to make an HTTP request and then instantiate this module with the resulting Buffer.

Doug - you are wicked fast!  If you help me with an example of that I will submit a PR to document it in the readme.  Deal?  I'm not a buffer/streams guy ... yet.

No problem :) Perhaps you just always catch me at a time that I'm ready to respond ;)
var express = require('express')
var getRawBody = require('raw-body')
var https = require('https')
var serveFavicon = require('serve-favicon')

createApp(function (err, app) {
  app.listen(3000, function (err) {
    if (err) throw err
    console.log('Express listening on port 3000')
  })
})

function getRemoteContent(url, callback) {
  var req = https.get(url)

  req.once('error', callback)
  req.on('response', function (res) {
    getRawBody(res, callback)
  })
}

function createRemoteServeFavicon(url, callback) {
  getRemoteContent(url, function (err, buf) {
    if (err) return callback(err)
    callback(null, serveFavicon(buf))
  })
}

function createApp(callback) {
  var app = express()

  createRemoteServeFavicon('https://d1ir1l1v07ijd0.cloudfront.net/img/ico/favicon.ico', function (err, favicon) {
    if (err) return callback(err)

    app.use(favicon)

    populateRoutes(app)

    callback(null, app)
  })
}

function populateRoutes(app) {
  app.get('/', function (req, res) {
    res.send('hello, world')
  })
}

I will submit a PR to document it in the readme.

I wouldn't accept a PR of the above extremely complex example (it's so complex because Node.js does not allow for sync network calls). I'll still add an example of "getting a Buffer from somewhere".

Wow!  Thanks Doug!


Fix for node 6

Took fix from: https://github.com/themikenicholson/passport-jwt/issues/62 so it will work with node 6.

Hey @mjcuva , not actively working on this, but would it help if I merged this in?

Also @mjcuva see you at your new office warming today?


Crash when linking Tesla Coil attached to a Solar Panel

This crash occurred while trying to link a Tesla Coil attached to one of Solar Village's Solar panels using the Tuning Rod. The Coil had earlier been attached and linked without issue, the problem arose when one was destroyed and replaced. Crash log: http://pastebin.com/HhtrFnai

What machine is the other Tesla Coil attached to?

A Tech Reborn Macerator.

It's worth noting that I cannot replicate the crash on a new World.

Given where the crash happened (onTuningToolUse) the only things I can think of is that the Tuning Tool's NBT was broken, or that for some reason the Solar Panel's Tesla Coil failed to find the Tile Entity of the Macerator's Tesla Coil, both of which shouldn't really happen ever, and would be difficult to replicate in a "natural" circumstance (obviously it's easy to intentionally delete the Tesla Coil's Tile Entity or screw with the tool's NBT to force it)
I'll investigate further and add some checks to at least prevent a crash happening if either of those issues arise.


Support numpy v2

langchain-aws currently pinned to ^1

Is this planned to be done soon? There's now commonly used packages like thinc that require NumPy > 2 making it incompatible with langchain-community and langchain-aws, etc.

+1 for the questions and its importance. Is there a particular reason for ^1 pin?


[FEATURE]

Hello,
Nice job !
It will be also nice to be able to remove the UIApplicationDidEnterBackgroundNotification which hides the menu.
Do you have any workaround currently ? (the class is private)
Thanks and keep up this nice library,
Jean

Why is there a need to do this?
You can subclass the menu and unregister it for notifications right after
it registers if you want.
On Fri, Sep 30, 2016 at 2:06 AM hedtech<EMAIL_ADDRESS>wrote:

Hello,
Nice job !
It will be also nice to be able to remove the
UIApplicationDidEnterBackgroundNotification which hides the menu.
Do you have any workaround currently ? (the class is private)
Thanks and keep up this nice library,
Jean
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jonkykong/SideMenu/issues/80, or mute the thread
https://github.com/notifications/unsubscribe-auth/AFdl_yH9juEXWMT3ntP1ewPVM3fODFqEks5qvNEugaJpZM4KK4Le
.

Hi,
To keep the menu open when you come back on foreground.
The class is internal, impossible to subclass.
Thanks

@hedtech I understand it's internal.
Why does the menu need to stay open when you come back from the foreground?

@jonkykong to summarize :
Sometimes, Client > all
😺
This is not a bad idea to customize this "feature" instead of subclassing a whole class just for this

@juliengdt I will not be building this feature.
Feel free to read the guidelines for contributing and open a pull request with your changes.


Change Reason.Create to enforce a Guid id

The current .Create accepts any string and crashes run-time. Let's
use the compiler to remove a potential run-time error.
If we need it to be a Guid we should not allow strings, even if that
makes the method slightly easier to use. It does so at the expense
of making run-time errors more likely.
┆Issue is synchronized with this Asana task

Great point @TomasEkeli - what if we went one further and actually use a ConceptAs<Guid> called ReasonId. We could then have have an implicit operator on that that parsed the string and actually have the code passing in a string and the parsing would happen implicitly and fail in the same way.

What I want to avoid is that code that looks fine and builds fine crashes at run-time
Example:
Reason.Create("something not a guid", "A good reason", "description");
If we had a ReasonId : ConceptAs<Guid> with an implicit operator that does Guid.Parse we would still let this slip past the compiler and turn into a runtime exception.
Can we, perhaps, have strings as Ids instead of Guids?

new Guid() or Guid.Parse() will not evaluate at build time, so you still have the same problem. It will only be seen at runtime no matter what you do for that.
If we want to evaluate this at build time, we could create a Roslyn extension that does the check.
I'm not too keen on having it as a string, even though that would work in isolation. The reason is that we're looking at including rules, broken rules and reasons as part of the MetaModel and actually promoting Rules, BrokenRules and Reasons into Artifacts - which would then require them to be Guids.

➤ Einar Ingebrigtsen commented:
I will move this into Triage for prioritization for now and as a non-breaking change we'll add the ConceptAs<> for this, building on your Pull Request.

Based off of this PR - I did some improvements in #317 - closing this as it is captured in that.


feat(telemetry): add telemetry to worker

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 4 (0.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.05%) to 77.878%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

core/notification/handler.go
0
4
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.05%

Covered Lines:
2841

Relevant Lines:
3648

💛  - Coveralls


Add activation events for providing/resolving tasks (TaskProvider extension API)

This PR is related to issue #99797 and its consequent PR #99957.
This PR makes the following changes:

Add onTaskProvide:taskType activation event whenever VS Code queries TaskProviders for tasks
Add onTaskResolve:taskType activation event whenever VS Code needs to resolve a TaskProvider's task
Add and implement ITaskService.getPossibleTaskTypes(): Promise<string[]>
An async version of .taskTypes() which also checks all task definitions defined in package.json of (inactive) extensions
Make TaskQuickPick use this new getPossibleTaskTypes()
Task types for inactive extensions (that specify taskDefinitions in their package.json) also get listed now

Related activation events and triggers:

onTaskProvide:taskType triggered by selecting Show All Tasks in the Tasks: Run Task's TaskQuickPick
This is fired for every task type registered in TaskDefinitionRegistry (except for shell and process)
onTaskProvide:taskType triggered by selecting an extension top level entry in the Tasks: Run Task's TaskQuickPick
This is fired for just the selected task type
onTaskResolve:taskType triggered by trying to resolve a task, if it has a type defined

I recently added a TaskProvider for my extension, and noticed that in certain cases, it couldn't be resolved. After taking a look, it seemed to be caused by the extension not being activated yet, hence not having registered the TaskProvider. With this PR, extensions can now add a proper activation event to deal with providing/resolving their tasks.
I noticed while working on this that #99957 made it that extensions can activate on onCommand:...runTask or even * instead. This PR provides more specific activation events, instead of having to rely on the aforementioned events.
Another possibility that I have thought about but decided against:
Since we can use taskDefinitions (TaskDefinitionRegistry) to figure out which extensions will (should) provide TaskProviders for which types, we can automatically start an extension when we need to provide/resolve using such a provider. The taskDefinitions would basically also register the extension for the appropriate onTaskProvide/onTaskResolve activation events.
The same could be done for commands, since similar to taskDefinitions we can access commands too, including from inactive extensions. Since this auto-registration isn't actually the case for commands, I assume it shouldn't be the case for task definitions either.

It's been almost 2 months since I created this PR. Did I miss a step about submitting it somewhere?

@SchoofsKelvin I haven't had a chance to take a look at the PR yet. I will try to get to it this month.

It's been a year since I opened this PR, any news?
I've rebased (on main) to resolve merge conflicts and retested it two days ago, and in the meantime the PR checks have passed.

Hey @SchoofsKelvin sorry for the delay. Unfortunately, it looks like there are quite a few conflicts now to deal with before I can review the PR.


METHOD

I trying the method, and METHOD_NAIVE and METHOD_NAIVECONSEC is look like identicals.
If you want to see, I send the jupyter file in my fork.
Milan

Well the only real difference is that NAIVECONSEC will find maximum or minimum with consecutive values.  e.g. 1, 2, 2, 2, 1 is only found with NAIVECONSEC and not found with NAIVE as its truly quite naïve :).  Make sure your data has maxima or minima that are repeated multiple times.

This is an observation, but not an issue since the 2 methods often can return identical values.


Certification tests for Azure Event Hubs binding

Describe the feature
Certify Azure Event Hubs as GA in input/output binding
Release Note

RELEASE NOTE:

/assign

The IoT hub from "integration test" needs to move to conformance test because the "integration tests" are not officially supported in a GitHub pipelines and it overlaps in objective with our certification tests.
Instead of retry, let's validate reconnection. Add a scenario where the connection to EvenHubs is stopped for a few seconds and validate that publish and subscribe continues to work after connection is recovered.
For AAD authentication, validate one of the authentication options is fine but verify that the code is using the "shared" code for Azure auth.

@artursouza  Added a scenario covering reconnection, auth testing and IoT migration from integration. Does this look good?

@artursouza FYI -- this component cannot be certified until pending open issues are resolved, especially https://github.com/dapr/components-contrib/issues/1598
It would be very helpful to have a certification test that verifies this very situation. There may be required updates to this component as a result.


Sandy link not working

The link to sandy seems wrong, or sandy is down.
To reproduce, just try to add an email in https://bitcoincore.org/en/list/announcements/join/

Uff, this site should be updated to point to the bitcoin-core-dev mailing list

Is this still an issue?

Fixed by #610


Undo button also for when editing tokens

Is your feature request related to a problem? Please describe.
Currently users are only able to undo tokens when creating a new one.

Describe the solution you'd like
It could benefit users if the undo button was also displayed when editing already existing tokens
Definition of done

Edit token action can be reverted with the undo button
If the previous action is edit token, tooltip on the Undo button displays ' Undo "Edit Token"'

Added to Featurebase Roadmap : 🪙 Token organization enhancements

Migrated to featurebase

Added to Featurebase Request-	Undo and emergency exit


no implementation of read_data with these arguments

https://github.com/RvSpectML/EchelleInstruments.jl/blob/98d5a94f72a863b2cd97cb0b582265e3d4dca96b/src/neid/io.jl#L261
Assuming fn is a String

Fixed in fadbe7793b4d35152d0312a9bf29981dfd41a59a


fix(module:select): unable to trigger nzScrollToBottom when using dis…

…play scaling (#1796)
close #1796
PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our guidelines: https://github.com/NG-ZORRO/ng-zorro-antd/blob/master/CONTRIBUTING.md#commit
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Application (the showcase website) / infrastructure changes
[ ] Other... Please describe:

What is the current behavior?

Issue Number: 1796
What is the new behavior?
Does this PR introduce a breaking change?
[ ] Yes
[x] No

Other information

Hi, @itryan thanks for your pr very much, please add test so we can accept this pr.

Due to no progress for a long time, this issue will be closed. Please contact us if you have any questions.


How to get some fake currency in test net?

Hello:
As I am new to this SDK, I have a few questions to ask.
I think if I have a main net wallet address, I can use it to receive real cryptocurrencies, like: BTC, ETH or USDT.
But if I have only test net wallet address, where and how can I get some free or fake currencies, so I can do some testings.
If I have two test net addresses generated by different private key, can I use the test net address to send and receive fake currencies, just for testing to know the process.
Please advise,
Thanks,

Hello @zydjohnHotmail,
Can we please move the discussion to https://discord.com/channels/847940290903932939/914832388431958036
I'll be able to answer all of your questions related to use cases there. Github issues it more for technical issues with the SDKs and not so well suited for support discussions.
As for the question the testnet currencies are obtainet from testnet faucets. You can find example links to faucets on each blockchain related part of the docs here https://apidoc.tatum.io/


Add video embed for "latest episode" in right rail, podcast section page

Desktop:

iPad Mini:

iPhone SE:

 Video on Podcast landing page.


support eslint@8

Most dependencies already updated to support eslint@8. Remaining are tracked here:

jsx-a11y: https://github.com/jsx-eslint/eslint-plugin-jsx-a11y/pull/810
react: https://github.com/yannickcr/eslint-plugin-react/pull/3059
react-hooks: https://github.com/facebook/react/pull/22248 - merged but not released yet

Resolved in https://github.com/ph-fritsche/eslint-config/blob/97cfa58abdf3440b0fea3ba2cc0c61637876649f/package.json


Clarify SSL Documentation

Add method description (ideally with examples) to scaladoc. Concretely - withSSL() and withSSLContext() methods. Should one use one? Which one? Or both? In which order? And so on.

While we look into ways to better represent this transparently in our documentation.
withSSL
withSSLContext
Are present with full examples that demonstrate why you might use either use case, generally based off what information you have available. However we might be able to help you specifically if you give a more clear definition of what you are looking to accomplish.
Glad to help however we can

@ChristopherDavenport Thanks, I've not been able to find those examples. However I figured that out myself somehow. By calling both methods. So the examples really came in handy, thank you. Maybe reference to them somehow int the scaladoc or create a documentation page?


WIP/ENH: Add fast foward attack tests

I've added this initial test to try to replicate a fast forward attack. For some reason, the updater doesn't fail. The process is the following:
1.- The repository writes the original metadata (snapshot_version -> 2)
2.- The client obtains that piece of metadata
3.- The repository writes a fast-forwarded version of the metadata (snapshot version -> 100)
4.- The client obtains that metadata by syncing (the client loads version 100)
5.- The repository writes a non-forwarded version of the metadata (snapshot_version -> 3)
6.- The client downloads it, and doesn't err on it (loaded snapshot version on the client is now 102)
Is this intended behavior? If so, any suggested way to test the FF attack? should I set this to UINT_MAX?
Ping @vladimir-v-diaz @awwad
I'll update this as code is written/fixed.

Issue #414 is to implement the ability for a client to recover from a fast
forward attack.  If this unit test is for that, then it is expected to
trick the current implementation (because it isn't implemented yet). If the
client is accepting a version lower than what it currently trusts, then
that's a bug / security issue.  The client should block rollback attacks.
On Jan 27, 2017 6:33 PM, "Santiago Torres"<EMAIL_ADDRESS>wrote:

I've added this initial test to try to replicate a fast forward attack.
For some reason, the updater doesn't fail. The process is the following:
1.- The repository writes the original metadata (snapshot_version -> 2)
2.- The client obtains that piece of metadata
3.- The repository writes a fast-forwarded version of the metadata
(snapshot version -> 100)
4.- The client obtains that metadata by syncing (the client loads version
100)
5.- The repository writes a non-forwarded version of the metadata
(snapshot_version -> 3)
6.- The client downloads it, and doesn't err on it (loaded snapshot
version on the client is now 102)
Is this intended behavior? If so, any suggested way to test the FF attack?
should I set this to UINT_MAX?
Ping @vladimir-v-diaz https://github.com/vladimir-v-diaz @awwad
https://github.com/awwad
I'll update this as code is written/fixed.
You can view, comment on, or merge this pull request online at:
https://github.com/theupdateframework/tuf/pull/423
Commit Summary

WIP/ENH: Add fast foward attack tests

File Changes

A tests/test_fast_forward_attack.py
https://github.com/theupdateframework/tuf/pull/423/files#diff-0
(257)

Patch Links:

https://github.com/theupdateframework/tuf/pull/423.patch
https://github.com/theupdateframework/tuf/pull/423.diff

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/theupdateframework/tuf/pull/423, or mute the thread
https://github.com/notifications/unsubscribe-auth/ADW5c4r9VlGL1-L3LbEbn5x1FWsIFMdzks5rWn6vgaJpZM4LwU34
.

So we've figured out why it doesn't raise an exception. Note, though, that the client has not actually updated to the old metadata. In other words, metadata on disk remains correct, but an error is not raised, when it should be.
In your test, this happens:

Repo writes version 1 of timestamp and version 1 of snapshot.
Client downloads and validates them successfully.
Repo writes version 2 of timestamp and version 101 of snapshot. (writeall actually increments the 100 you stick in repo.snapshot.version)
Client downloads and validates them successfully.
Repo writes version 3 of timestamp and version 3 of snapshot (writeall actually increments the 2 you stick in repo.snapshot.version)
Client downloads and validates timestamp successfully, then looks at its indicated version of snapshot and sees that it's NOT GREATER THAN its existing snapshot version, and doesn't download the new snapshot.

The thing I would like to have happen differently is that at step 6 above, the client should raise an exception that explains that any one of the following three things is occurring (and it can't tell which):

The mirror contacted has outdated data, which is okay. We haven't updated, therefore.
We are contacting a server that is attempting a replay attack.
We have previously been fast-forward attacked, and the server we're contacting is either not aware of this or just hasn't issued new root metadata that would allow any affected clients to recover. (Or, in our case at this very moment, such code for that recovery doesn't exist. (: )

Some history...
Timestamp previously specified only the hash(es) and length of Snapshot, and the client knew to download a new Snapshot file if it's hash(es) (listed in Timestamp) changed.  We now list the version number of Snapshot in Timestamp, and therefore can potentially detect replayed metadata in advance.
Something we'd need to decide...
Should we:
(1) throw an exception before we actually download replayed metadata (and then reject), or
(2) check for an updated Snapshot by inspecting its hash(es) in Timestamp and raise a ReplayedMetadataError when we retrieve it.
There might be some merit to approach (2), because we check for version numbers in one part of the code (after we download metadata and not also we we inspect referenced metadata) and ReplayedMetadataError is raised consistently for all roles.
For example, if we were to simulate a replay attack with the Timestamp role, the code would raise ReplayedMetadataError instead of an exception that says that an outdated mirror, or a Fast Forward or Replay attack might be the problem.

How do we know the metadata is replayed in case 1?  What info is there in
the timestamp file that says this?
Justin
On Mon, Jan 30, 2017 at 5:27 PM, Vladimir Diaz<EMAIL_ADDRESS>wrote:

Some history...
Timestamp previously specified only the hash(es) and length of Snapshot,
and the client knew to download a new Snapshot file if it's hash(es)
(listed in Timestamp) changed. We now list the version number of Snapshot
in Timestamp, and therefore can potentially detect replayed metadata in
advance.
Something we'd need to decide...
Should we:
(1) throw an exception before we actually download replayed metadata (and
then reject), or
(2) check for an updated Snapshot by inspecting its hash(es) in Timestamp
and raise a ReplayedMetadataError when we retrieve it.
There might be some merit to approach (2), because we check for version
numbers in one part of the code (after we download metadata and not also we
we inspect referenced metadata) and ReplayedMetadataError is raised
consistently for all roles.
For example, if we were to simulate a replay attack with the Timestamp
role, the code would raise ReplayedMetadataError instead of an exception
that says that an outdated mirror, or a Fast Forward or Replay attack might
be the problem.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/theupdateframework/tuf/pull/423#issuecomment-276212208,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA0XD_f_zSF_EEh03mavuSCHIL06TIruks5rXmPagaJpZM4LwU34
.

timestamp.json includes the version number of snapshot.json
"snapshot.json": {
    "hashes": {
     "sha256": "c15b14217a3ad50ae2c136109983b7269d3bda42c4e1e530e30e7b5854b53a11"
    },
    "length": 678,
    "version": 1
}

https://github.com/theupdateframework/tuf/blob/develop/tests/repository_data/repository/metadata/timestamp.json#L13-L18

So without downloading the snapshot.json, all you know is that the
timestamp says the snapshot has an old version.  I suppose if you
download the snapshot.json, you can better detect what is happening in some
cases (such as when the files are served by different parties...
On Mon, Jan 30, 2017 at 7:25 PM, Vladimir Diaz<EMAIL_ADDRESS>wrote:

timestamp.json includes the version number of snapshot.json
"snapshot.json": {
"hashes": {
"sha256": "c15b14217a3ad50ae2c136109983b7269d3bda42c4e1e530e30e7b5854b53a11"
},
"length": 678,
"version": 1
}
https://github.com/theupdateframework/tuf/blob/
develop/tests/repository_data/repository/metadata/timestamp.json#L13-L18
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/theupdateframework/tuf/pull/423#issuecomment-276236150,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA0XD4NdKI7ONthOr6aCTV1RqhoUZHBFks5rXn9vgaJpZM4LwU34
.

The issue is valid (and after #1444 I intend to take a stab at it as well) but this specific PR has not seen action in 4 years: closing, please reopen if needed


php7 + opcache + mongodb: Query and php array is getting changed randomly.

We found some strange behaviour where queries sent to mongodb don't match what we intended to send.
After digging deeper we found that under load with multiple requests handeled concurrently by php-fpm, the system randomly starts changing the php array (!).
This only happens when the array is sent to the mongodb find operation (other operations not tested).
We have only seen it changing the array when it has been sent to mongodb. Not calling ->find() does not produce the error.
Also opcache need to be enabled for the file where the query array is defined. With opcache disabled it will not fail.
The array is changed in a way that 'static' contents seem to be removed. We don't know if any more is getting replaced or changed. For example the part '[10, 12]' is replaced with NULL in our test case.
Replacing one value with dynamic content eliminates the error too: repalce for example 12 with (int)$_GET['id'], call the test script with parameter test.php?id=10 and it will NOT fail.
When using json_decode(json_encode($test), true) before submitting the data to ->find it will NOT fail and not change any contents of $test.
The database and selection does not exist in our test case.
We have tested with
ext-mongodb 1.1.8
mongodb/mongodb 1.0.2
PHP 7.0.8-4
Below the test script, run with apache benchmark

require __DIR__ . '/../vendor/autoload.php';

$test = ['test' => ['$in' => [10, 12]]];

$client = new MongoDB\Client();
$client->selectCollection('a','b')->find($test);

file_put_contents('/tmp/mongodb-errors.log', (int)(serialize($test) == 'a:1:{s:4:"test";a:1:{s:3:"$in";a:2:{i:0;i:10;i:1;i:12;}}}'), FILE_APPEND);

Run ab test:
(optional) > sudo service php-fpm restart;

ab -c 40 -n 1000 http://your.domain.goes.here/test.php

Example result: 1 = success, array not changed, 0 = error, array has been changed. '[10, 12]' has been nulled.
11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111111111000000000000000000000000000000000000
00000000000000000000000100000000000000000000000000000000000000000000000000111111111111111111111111111111111111111111111111
11100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000111111111111111000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000001111111```

This seems like it may be a duplicate of https://github.com/mongodb/mongo-php-driver/issues/293, which was caused by APCu. Can you read through that issue and confirm?

php -i | grep -i apcu
does not give me any result. I think we are not using APCu?

If you need any help reproducing the issue let me know. I'll help where I can as this is an important issue for us.

Replacing one value with dynamic content eliminates the error too: replace for example 12 with (int)$_GET['id'], call the test script with parameter test.php?id=10 and it will NOT fail.
When using json_decode(json_encode($test), true) before submitting the data to ->find it will NOT fail and not change any contents of $test.

This sounds quite bizarre, as I don't see how modifying the value beforehand would affect the driver's internal behavior. I imagine it may have implications for opcache, though.
When the MongoDB\Driver\Query is constructed, the argument is immediately serialized to BSON. That BSON is what is ultimately sent to the server. Can you use server-side profiling to log queries sent the to server and compare whether they are also be corrupted? The comment option to find() may be used to make it easier to track these queries.
Also, I noticed that you were dumping serialize($test) after calling find(). I might suggest moving those comparisons to the lines immediately before and after the library constructs a MongoDB\Driver\Query object (here) for testing purposes.

More tests made:
Before and after the find call:
require __DIR__ . '/../vendor/autoload.php';

$test = ['test' => ['$in' => [10, 12]]];

$client = new MongoDB\Client();
$a = (int)(\serialize($test) == 'a:1:{s:4:"test";a:1:{s:3:"$in";a:2:{i:0;i:10;i:1;i:12;}}}');
$client->selectCollection('a','b')->find($test);
$b = (int)(\serialize($test) == 'a:1:{s:4:"test";a:1:{s:3:"$in";a:2:{i:0;i:10;i:1;i:12;}}}');
file_put_contents('/tmp/mongodb-errors.log', $a . '-' . $b . " ", FILE_APPEND);

Results:
looks like error manifested like this
1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-0 1-0 1-0 1-0 1-0 1-0 1-0 1-0 1-0 1-0 1-0 1-0 1-0 1-0 1-0 1-0 0-0 1-0 1-0 0-0 0-0 1-0 1-0 0-0 0-0 0-0 0-0 0-0 0-0 0-0 1-0 0-0 0-0 0-0 0-0 0-0 0-0 1-0 0-0 0-0 0-0 0-0 0-0 0-0 0-0 0-0 0-0 0-0 0-0 0-0 0-0 0-0 0-0 0-0 0-0 0-0
and in a laterrun the error disappeared again:
0-0 0-0 0-0 0-0 0-0 0-0 0-0 0-0 0-0 0-0 0-0 0-0 0-1 0-1 0-1 0-1 1-1 0-1 0-1 1-1 0-1 0-1 1-1 1-1 0-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 0-1 0-1 0-1 0-1 0-1 1-1 1-1 1-1 1-1 1-1 1-1 0-1 0-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1

And now as you suggested before and after  MongoDB\Driver\Query is constructed
$a = (int)(\serialize($this->filter) == 'a:1:{s:4:"test";a:1:{s:3:"$in";a:2:{i:0;i:10;i:1;i:12;}}}');
$ret = new Query($this->filter, $options);
$b = (int)(\serialize($this->filter) == 'a:1:{s:4:"test";a:1:{s:3:"$in";a:2:{i:0;i:10;i:1;i:12;}}}');
file_put_contents('/tmp/mongodb-errors.log', $a . '-' . $b . " ", FILE_APPEND);
return $ret;

first run:
1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 1-0 0-0 0-0 0-0 1-1 0-0 0-0 0-0 0-0 0-0 0-0 0-0 0-0
second run:
0-0 0-0 0-0 0-0 0-1 1-0 0-0 0-0 0-0 0-0
another run after php-fpm restart
0-0 0-0 0-0 0-0 0-0 0-1 0-1 1-1 1-1 1-1 [ more 1-1 here] 1-1 1-1 1-0 1-0 0-0 0-0 0-0 0-0

logging queries in mongodb server:
'comment' => 'abc' used:
After running I dumped the result into abc.log
less /var/log/mongodb/mongod.log | grep abc > abc.log
The log file is attached to this issue.
In line 199 is the first error happening:
"{ $comment: "abc", $query: { test: { $in: [] } } }"
The values inside the array have been removed.
It doesn't look like the corrupted php $test array is NOT exactly linked to the number of wrong queries. But still somewhat related.

Here my list of extensions:
Core
PDO
Phar
Reflection
SPL
SimpleXML
Zend OPcache
calendar
cgi-fcgi
ctype
curl
date
dom
exif
fileinfo
filter
ftp
gd
gettext
hash
iconv
json
libxml
mbstring
mongodb
openssl
pcre
pdo_pgsql
pgsql
posix
readline
session
sockets
standard
tokenizer
wddx
xml
xmlreader
xmlwriter
xsl
zlib

Is anyone able to reproduce the issue?

In both of your tests (first around Collection::find() and secondly around the Query construction) where you were comparing the serialized filter array to an expected string, you appear to have a mix of both comparisons being false at different times. That hints at some sort of corruption before we even get to the driver code.
If Query::__construct() was at fault, I might expect your output to be a mix of 1-1 and 1-0, but I would not expect the first comparison to ever be false. Essentially, this is failing for you:
$test = ['test' => ['$in' => [10, 12]]];
$a = (int)(\serialize(['test' => ['$in' => [10, 12]]]) == 'a:1:{s:4:"test";a:1:{s:3:"$in";a:2:{i:0;i:10;i:1;i:12;}}}');

Have you tried testing that on its own without using the driver at all?

The log file is attached to this issue.

I don't see any files attached to your earlier posts. You may want to double-check that.

I agree, the problem seems to persist across multiple calls. It sometimes comes and sometimes goes away again. And again it only happens when multiple calls are procesed concurrently..
Without the mongodb driver or even without calling ->find($test); method it does not happen.

don't see any files attached to your earlier posts. You may want to double-check that.

Here we go:
abc.log.txt

I have a similar problem which I think is related to this. Also noticed that when I disable opcache it works without a problem.
The query which failes is: $table->find(['_type' => ['$in' => ['website', 'rootnode', 'iqcms']]]); It started to return 0 results. I rewrote the query to test if it mattered to: ['$or' => [['_type' => 'website'],  ['_type' => 'iqcms'],  ['_type' => 'iqcms']]];
The latter query eventually started producing the following exception:
Fatal error: Uncaught MongoDB\Driver\Exception\ConnectionException: $and/$or/$nor must be a nonempty array in /var/www/iqcms-1.6/vendor/mongodb/mongodb/src/Operation/Find.php:180
I test it by doing a ab -n 4000 -c 20 http://dgd70.localhost.iqcms/cms/forgot and after 500-5000 requests (seems random) it starts to produce exceptions because the query isn’t returning any results. The code base is a bit large and I haven’t isolated the query to see if I can reproduce it with a smaller set of code.
My opcache config:
[opcache]
zend_extension="opcache.so"
opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=7963
opcache.max_wasted_percentage=5
opcache.use_cwd=1
opcache.validate_timestamps=1
opcache.revalidate_freq=60
opcache.fast_shutdown=1
I encounter the problem with the 1.1.8 driver aswell as the 1.2.0alpha.
Let me know if I need to provide more data.

Seems like this is caused at a lower level than the php library, possibly some memory corruption going on here? I created that issue in the mongodb-php-driver repository to get some help from there.

@cb-msales: Does your opcache configuration agree with @Visualq?
Would either of you be able to attempt reproducing the problem with the Zend memory manager disabled? This will require setting the USE_ZEND_ALLOC environment variable to 0. To ensure that the environment variable is respected, you should see "Zend Memory Manager" marked as "disabled" in phpinfo().
This blog post may be helpful for specifying an environment variable in PHP-FPM.
@derickr suggested this on the off chance that Zend MM is hiding the underlying issue. Reproducing without it may provide a better chance at exposing the root cause.

@jmikola It seems that disabling the Zend Memory Manager does not solve the problem. The problem keeps occuring.

Sorry, @Visualq, we had not expected the problem to go away with this, but rather, it should be easier to deterministically reproduce the problem.

Ah yes, I didn't properly read the question. To properly answer the question: I was able to reproduce the problem with Zend Memory Manager disabled. Is there anything I can provide to help determining the cause? The data used to make this problem appear is sensitive and therefore I can't make it publicly available.

@Visualq Could you try the code snippet I posted at the beginning? Let's see if it is reproducible.

@jmikola Sorry for my late reply. I used the standard opcache config (no parameters set in php.ini) and in a second test I also used Visualq's exact config. The bug appeared every time.

@cb-msales I managed to reproduce the problem with the snippet you provided. took around 1500 requests before the 0's started to appear. However after the first 0 appears the array will not be back. It will fail every time.

Any progress on this problem? It prevents me from using PHP 7 + Mongo + opcache in production.

Hi, @Visualq have you tried to json_encode and directly decode your variables passed to mongodb calls?
It seems to work fine for us as a temporary workaround because the variables contents don't get optimized away anymore. No reference can be passed to MongoDD this way.
->find( json_decode(json_encode($query), true) );
Of course that's just a temporary solution and doesn't replace a fix of the underlying issue.

Hi @cb-msales, Thank you, but as much as I appreciate the workaround I have feeling this problem will occur at more places which will lead to unexplainable events causing me to spend to much debug time ;). I think I rather wait for the proper solution. I will try the json_decode/encode trick later on just to see if that works.

We also ran into this issue, with queries using the aggregation framework.
Under load we'd find no results being returned by the query, then after around 10 mins or so results would appear again before disappearing a short while later.
Turning off the opcache has fixed this issue but really isn't an ideal solution as its impacting performance.
We're running:

php 7.0.11-1+deb.sury.org~xenial+1
mongodb 1.1.8
libmongoc 1.3.5
3.2.10

Happy to send over any more info that might help track down this issue :-)

I can confirm similar issue with aggregate.
When running aggregate queries with PHP7, we start getting following exceptions
exception: Expression $cond takes exactly 3 arguments. 0 were passed in.

seems like query is corrupted before hitting the database
same queries have random results (either result or exception)
problem appears under high load only
Apache restart helps for 10-20 mins, then the exceptions reappear
PHP7 + opcache

Today, we ran into exactly the same problem, we have 2 servers behind a load balancer, one server started returning no results for a query, which works on the second server. Both severs are using the same database.
After a restart of php-fpm the problem disappeared.
7.0.8-0ubuntu<IP_ADDRESS>
mongodb 1.1.6   stable (installed from pecl)
mongodb server 2.6.11

@derickr, @jmikola FWIW, This is still occurring on the just released mongodb 1.2.0 extension w/ mongod 3.2.10 using the original code from @cb-msales July 20 comment. Commenting out the find() negates the issue.  Doing the json_decode(json_encode($query)) workaround also negates the issue.
$ php -v
PHP 7.1.0RC6 (cli) (built: Nov  9 2016 15:11:15) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.1.0-dev, Copyright (c) 1998-2016 Zend Technologies
    with Zend OPcache v7.1.0RC6, Copyright (c) 1999-2016, by Zend Technologies
    with Xdebug v2.5.0-dev, Copyright (c) 2002-2016, by Derick Rethans

$ php --ri mongodb
mongodb
mongodb support => enabled
mongodb version => 1.2.0
mongodb stability => stable
libmongoc version => 1.5.0
libbson version => 1.5.0

Directive => Local Value => Master Value
mongodb.debug => no value => no value

@cb-msales I was also able to get the correct results if I reset the opcache with opcache_reset(); at the head of the script. Not optimal at all since it negates one of the big benefits of PHP 7.

@moderndeveloperllc: Thanks for confirming. I've opened PHPC-848 to track this and will set aside some time next week to investigate. I'd also like to attempt reproduction with PHP 7.1, which should be released by then.

@jmikola Good luck with that! I spent some time yesterday playing around on the userland end of things.

I did an opcache_invalidate($script, true) for each of the 13 scripts called (including composer scripts) and the issue still occurs, so the issue is almost certainly driver code.
I added opcache_get_status() to the logging output. Nothing popped out as being different for working/nonworking calls - only the hit counter.
Issue only happened with concurrent threads which means that the file_put_content() logs are not in execution order so hopefully you have better tools.
Nice to know 7.1 will get here before the new year!

Issue only happened with concurrent threads which means that the file_put_content() logs are not in execution order so hopefully you have better tools.

@moderndeveloperllc: what's the relation to "concurrent threads". If I understand the thread correctly, folks have reproduced this with PHP FPM, where each worker handles a single request at a time. On that note, can you share your PHP and FPM configurations (i.e. php-fpm.conf and the www.conf pool configuration)?

@jmikola Thank you for looking into this bug.
I took the liberty testing the bug with 1.2 driver and PHP 7.1 RC6. I managed to reproduce the problem quite quickly.
I attached the php.ini and php-fpm.conf which I'm using to produce the bug. (www.conf is included in the fpm config.)
php.ini.txt
php-fpm.conf.txt

@Visualq: Thanks, that should help quite a bit.

@jmikola I was just testing with the original setup that used ab. If I set the concurrent threads down to 1 (ab -c 1 -n 1000), I didn't see the issue in the first thousand. If the issue happening with PHP-FPM, then perhaps 'concurrency' is a false criterion.

@moderndeveloperllc I couldn't reproduce the issue either using 1 thread for 100k requests.

@moderndeveloperllc, @Visualq: Apologies for assuming PHP FPM was being used here. To confirm, the reproductions are with Apache and mod_php?

@jmikola I'm using nginx 1.11.6 with php fpm. Not Apache.

@Visualq: When you said "I couldn't reproduce the issue either using 1 thread for 100k requests", were you referring to a single FPM worker? I may be a bit confused because it's my understanding that each FPM workers are separate processes, not threads, and each only serves one request at a time. The only concurrency is if a pool contains multiple workers. The relevant bits from your config are:
pm = dynamic
pm.max_children = 64
pm.start_servers = 6
pm.min_spare_servers = 4
pm.max_spare_servers = 8

@jmikola ah no I meant I was using ab -c 1 -n 100000. I didn't change the fpm config.

Just to follow up, I've been able to reproduce the issue locally with the provided configuration files and scripts and am actively investigating the cause. In addition to the library example, I've reproduced it with the driver directly (as expected) and also with MongoDB\BSON\fromPHP(), which hints that BSON encoding is to blame.
Library Query
<?php

require __DIR__ . '/vendor/autoload.php';

$test = ['test' => ['$in' => [10, 12]]];

$client = new MongoDB\Client;
$client->selectCollection('a','b')->find($test);

$result = (int)(serialize($test) == 'a:1:{s:4:"test";a:1:{s:3:"$in";a:2:{i:0;i:10;i:1;i:12;}}}');
file_put_contents('/tmp/mongodb-errors.log', $result, FILE_APPEND);

Extension Query
<?php

$test = ['test' => ['$in' => [10, 12]]];

$query = new MongoDB\Driver\Query($test);
$manager = new MongoDB\Driver\Manager;
$cursor = $manager->executeQuery('a.b', $query);

$result = (int)(serialize($test) == 'a:1:{s:4:"test";a:1:{s:3:"$in";a:2:{i:0;i:10;i:1;i:12;}}}');
file_put_contents('/tmp/mongodb-errors.log', $result, FILE_APPEND);

Extension BSON Encoding
<?php

require __DIR__ . '/vendor/autoload.php';

$test = ['test' => ['$in' => [10, 12]]];
$bson = MongoDB\BSON\fromPHP($test);

$result = (int)(serialize($test) == 'a:1:{s:4:"test";a:1:{s:3:"$in";a:2:{i:0;i:10;i:1;i:12;}}}');
file_put_contents('/tmp/mongodb-errors.log', $result, FILE_APPEND);

@cb-msales, @Visualq, @moderndeveloperllc: I'd appreciate it if you guys could test out the patch in https://github.com/mongodb/mongo-php-driver/pull/481 and report back on whether that addresses the problem. It appears to fix the issue on my local environment (testing several rounds of 200k requests through ab), which is a 3-worker FPM deployment with @Visualq's OPcache configuration in effect.
I've open the PR against the v1.1 branch, but it will cleanly apply to master as well if you'd like to test on 1.2. If it does resolve the issue, I will get this released ASAP as 1.1.10 and 1.2.1.

Hi @jmikola, I applied the patch to the master branch and ran a few tests. It appears to be working! no more abnormalities.
In the patch you add an equivalent macro for working with the apply counter for PHP 5.x however I could not reproduce this problem with PHP 5.6 (pre-patch).

In the patch you add an equivalent macro for working with the apply counter for PHP 5.x however I could not reproduce this problem with PHP 5.6 (pre-patch).

The macro for PHP 5.x always evaluates to true, since it has no notion of immutable arrays. It was just easier to keep a macro in place instead of requiring #if blocks around the code in bson.c for PHP 7.x and PHP 5.x.

Got it, thanks!

1.1.10 and 1.2.1 have been released with the patch. In addition to addressing the OPcache issue, we resolved a bug with detecting circular references in arrays and objects, which is also relevant to PHP 5.x users.


[tls] MAISTRA-2051: Add extended TLS options

MAISTRA-2051: TLS Config: Add TLS related feature flags
Partial pick of 1fe34221d5 for Maistra 2.1 / Istio 1.8 rebase.
This registers the feature flags for TLS related configuration.  The
settings have been updated for the v3 Envoy APIs now in use by Istio.
Related Maistra issues: MAISTRA-1787, MAISTRA-1456, MAISTRA-1681,
MAISTRA-1697, MAISTRA-1698, MAISTRA-1699
MAISTRA-2051: TLS Config: Set TLS options for istiod and webhooks
Partial pick of 1fe34221d5 for Maistra 2.1 / Istio 1.8 rebase.
This configures the TLS options for the main istiod server and for
webhooks based on the previously added TLS feature flags.
Related Maistra issues: MAISTRA-1787, MAISTRA-1456, MAISTRA-1681,
MAISTRA-1697, MAISTRA-1698, MAISTRA-1699
MAISTRA-2051: TLS Config: Set TLS options in gateway listeners
Partial pick of 1fe34221d5 for Maistra 2.1 / Istio 1.8 rebase.
This sets TLS options when building gateway listeners based on
previously added TLS feature flags.
Related Maistra issues: MAISTRA-1787, MAISTRA-1456, MAISTRA-1681,
MAISTRA-1697, MAISTRA-1698, MAISTRA-1699
MAISTRA-2051: TLS Config: Set TLS options in BuildInboundFilterChain
Partial pick of 1fe34221d5 for Maistra 2.1 / Istio 1.8 rebase.
This sets TLS options in the authn code in BuildInboundFilterChain
based on the previously added TLS feature flags.  This removes the
upstream EnableTLSv2OnInboundPath flag to avoid conflicting TLS
settings.  That was introduced in fa0d260345 -- upstream PR: #27500
Related Maistra issues: MAISTRA-1787, MAISTRA-1456, MAISTRA-1681,
MAISTRA-1697, MAISTRA-1698, MAISTRA-1699
MAISTRA-2051: TLS Config: Update charts with TLS options
Partial pick of 1fe34221d5 for Maistra 2.1 / Istio 1.8 rebase.
This updates the charts to set the new TLS feature flags.  Validation
tests in the operator code are skipped because we add TLS settings in
the charts, but don't add them to the Go types.
Related Maistra issues: MAISTRA-1787, MAISTRA-1456, MAISTRA-1681,
MAISTRA-1697, MAISTRA-1698, MAISTRA-1699

/test integration-maistra-mc

/test integration-maistra-mc

You're right. I created an issue in the backlog.

@jewertow @dgn I wonder if that was this ever fixed :) Could you share the issue number where we are tracking it as I can't really find any commit "unskipping" those tests on our end?

It seems that I didn't create that issue at all. I don't know why I said that I did it, but it does not matter today.
Anyway I think it's not worth fixing those tests, because we don't use upstream operator nor even test it on our prow.


Example giving error: 'RCTBridgeModule.h' file not found

I tried to run the example code, but got the following error:
'RCTBridgeModule.h' file not found

@nylsoo Have you managed to resolve this problem?
I have a similar one after doing all the steps in the IOS Setup:

'React/RCTDefines.h' file not found
'RCTBridgeModule.h' file

The setup guides got updated in the new version of this lib (2.7.2.). Unfortunately the example is a bit outdated by now. Please try with the new minimal example code which you can find in the README. It's tested for Android and iOS with RN 0.61

Hey did you manage to resolve the problem? I'm facing the same one that @AshinePl has. This is in my own application, not the example.

@Thianzeren My problem was with the "framework search paths" I was setting the "header search paths" instead. After I followed the iOS setup manual carefully, everything worked like a charm

@Thianzeren My problem was with the "framework search paths" I was setting the "header search paths" instead. After I followed the iOS setup manual carefully, everything worked like a charm

I’m using react native v0.62.2 with pods, should I still do the steps for the manual installation? I currently only have $(inherited) in my Framework Search Paths

Managed to fix this as I found out that I had the KontaktBeacon libraries in both my "linked binary with libraries" and also in my Pods. I removed it from my "linked binary with libraries" and it builds correctly!

@Thianzeren Great to hear that. You should either follow the automatic install with Pods or the manual install and not mix both.


Brunch build: New plugins are not getting used

Install brunch packages, do a brunch build
Add new brunch plugin to package.json (for example sass-brunch) and some file that the plugin may compile (app/style.sass)
Do a brunch build.

Brunch would notice we've installed a new plugin and execute npm install for us. This is good, but after that the plugin would not get loaded with Brunch. And the .sass file would not be compiled.

Fixed  I suppose


API - Search multiple keywords using quotes

Searching with quotes is working find in the UI but doesn't seem to work or be supported in the API calls: genepage, genome, region.
This works:
https://knetminer.rothamsted.ac.uk/araknet/genepage?list=AT2G32950&keyword=nitrate+AND+content
This doesn't work:
https://knetminer.rothamsted.ac.uk/araknet/genepage?list=AT2G32950&keyword="nitrate+content"

The backend search is expecting correctly formed search phrases. The UI is parsing these from free text entered by the user, so if the user enters "nitrate+content" then the UI is first translating that into 'nitrate AND content' (without the quotes) before sending that back to the backend for processing. Therefore if you pass back the whole original unparsed phrase it is bound to fail.
You have to decide whether you want the UI to be parsing the search strings into backend-compatible search strings, or whether you want the backend to parse those strings itself. This is because the original Knetminer design has mixed up backend and frontend logic (this is one of many areas where it has done so) meaning the two cannot be separated.
The frontend parses search strings and constructs calls to the backend to carry out search, but it ALSO uses the parsed search strings to update UI elements and allow things like clickable lists of keywords. Meanwhile the backend is expecting to receive pre-parsed search strings that it can process without further effort.
If the backend is to start receiving raw search strings then parsing code will have to be added to it. Then the frontend would be modified to pass it the raw unparsed strings. However, the UI would still need to parse the strings itself for its own purposes. This is a duplication that would lead to divergence in future developments if search fixes were not made equally on both sides.
Changing the backend to accept raw strings instead of parsed ones will break all existing third-party code that uses the API. You would have to be very careful how you release it.
Changing the frontend to pass back raw search would lead to a duplication of code. Ideally if engineering Knetminer from scratch you would have had the backend returning the parsed keywords along with the results for the frontend to use instead of parsing them twice, but again doing this now this would lead to a change in the results format of the backend, quite a major change in the related frontend code, and again breaking the existing API promises to third-party code.
So all in all I would probably advise against this change unless you are willing to spend the time and effort involved in the final paragraph above (pass raw search to the backend, refactor the frontend to use keywords from the backend instead of parsing its own), and if you do wish to proceed, I would advise putting this in a later sprint as it is probably a whole sprint's worth of work in itself.

The UI is parsing these from free text entered by the user, so if the user enters "nitrate+content" then the UI is first translating that into 'nitrate AND content' (without the quotes) before sending that back to the backend for processing.

Really? I don't recall that "" is translated to AND. The query "nitrate content" produces different results to nitrate AND content. As far as I remember, the keywords are passed unprocessed to the backend searchLucene() method. Here it gets parsed using Lucene QueryParser and Query. Some special code has been written to deal with NOT statements but everything else including AND, OR, "", *, () is processed as a standard Lucene query syntax.
searchLucene(String keyword)
https://github.com/Rothamsted/knetminer/blob/24e4bc0148dc616c4c4a377ff3d2e784375b570c/common/server-datasource-ondexlocal/src/main/java/rres/knetminer/datasource/ondexlocal/OndexServiceProvider.java#L561
I don't know the client code very well, but it could be that the Query Suggester is parsing keywords too? Although again there is code on the backend side to do this:
writeSynonymTable(String keyword)
https://github.com/Rothamsted/knetminer/blob/24e4bc0148dc616c4c4a377ff3d2e784375b570c/common/server-datasource-ondexlocal/src/main/java/rres/knetminer/datasource/ondexlocal/OndexServiceProvider.java#L2565
Can you check again if there is a quick fix here to support "" in the API. I assign this back to you @dicknetherlands to review.
As part of issue #347 we can work on a more thorough refactoring of the KnetMiner backend.

i'll take another look - but pretty sure that if you pass back a term including quotes then the content is treated as a single phrase and isn't broken down further. Not sure how the + would be handled in any case as the logic uses AND not + - but will check.

The + is just used instead of space. My browser interprets + as space. Sorry if this was misleading.  And yes if you put quotes around your term then it’s treated as a single phrase which is different to AND/OR.

Looked at code. You are right - the frontend parsing is gone. It definitely used to be there, but it was removed during the previous phase of work, which I had forgotten about:
https://github.com/Rothamsted/knetminer/commit/51497e74b3b5106583f06fba5504c77db412b056
The backend parser passes the search term straight through to Lucene so if it includes quotes then those quotes also get sent straight to Lucene. Nothing to fix there - it works fine.
Looking back at your original request at the top I can see you're asking for a URL that ends with keyword="nitrate+content". I think the problem you are experiencing is a malformed URL, not a broken search. Specifically, the issue is affecting searches with plus signs in, not searches with quotes. You'll see the same effect with or without quotes.
When you put unescaped plus signs into the values in URLs they get translated into spaces as per the HTTP protocol. So this is in fact ending up server-side as keyword="nitrate content" and that is the search that is getting run. If you want to definitely send a plus sign in the middle of that, do this instead:
https://knetminer.rothamsted.ac.uk/araknet/genepage?list=AT2G32950&keyword="nitrate%2Bcontent"
In other words, watch out for HTTP URL encoding when constructing searches. I don't think there's anything broken with the search itself, and it definitely is not related to quotes.
Which takes us back to the frontend code. The code there that constructs the search query URL is not escaping the contents of the keyword string, and thus we see this problem because it passes the plus signs through unescaped. Simply urlencoding the keyword string in the UI javascript before appending it to the query URL should fix it. Here is the method that needs correcting:
https://github.com/Rothamsted/knetminer/blob/24e4bc0148dc616c4c4a377ff3d2e784375b570c/common/client-base/src/main/webapp/html/javascript/utils.js#L953

(NB. There is still some funny stuff going on in the backend with NOT terms, but that's a separate issue.)

Forget about the + signs. I wanted them to be translated to space.
This link is not working in Chrome:
https://knetminer.rothamsted.ac.uk/araknet/genepage?list=AT2G32950&keyword="nitrate content"
And neither does this work:
https://knetminer.rothamsted.ac.uk/araknet/genepage?list=AT2G32950&keyword="nitrate content"

I've checked the genepage, evidence, genome, qtl (region?) calls. The latter two don't seem to have any issues that I can see. The former two though do have a bug - the template that is used to construct the response page for each does not escape the quotes inside the JS that it generates, so you'll be seeing weird effects because of that (most likely a blank page). This is also a case of escaping the string correctly before inserting it into the template and needs to be fixed here:
https://github.com/Rothamsted/knetminer/blob/24e4bc0148dc616c4c4a377ff3d2e784375b570c/common/server-base/src/main/webapp/WEB-INF/views/genepage.jsp#L20
and here:
https://github.com/Rothamsted/knetminer/blob/24e4bc0148dc616c4c4a377ff3d2e784375b570c/common/server-base/src/main/webapp/WEB-INF/views/evidencepage.jsp#L20

Fixing this issue could also fix issue #380

Hi @mdonepudi  I'll send you example genepage and UI queries to search/test on Teams...

@KeywanHP

The aratiny/ client-UI on http://localhost:8080/ can be queried with keyword: "leaf size" and adding 1 gene in gene list: AT5G41315 . we can click the gene listed as output in GeneView table and it shows a small network in Network View (KnetMaps) with 23 nodes and 35 edges.

Doing a genepage API call for the same shows a slightly different (larger) network: http://localhost:9090/ws/aratiny/genepage?list=AT5G41315&keyword=leaf+size or even using http://localhost:9090/ws/aratiny/genepage?list=AT5G41315&keyword=leaf size (37 nodes and 53 edges in this case)

However, using "" quotes directly in genepage url fails (no network rendered): http://localhost:9090/ws/aratiny/genepage?list=AT5G41315&keyword="leaf+size"

Note: in this case, replacing "" with AND in genepage url does return the same network as client-UI (with 23 nodes and 35 edges): http://localhost:9090/ws/aratiny/genepage?list=AT5G41315&keyword=leaf AND size

What we want logic-wise is, e.g,

a search for leaf size/ leaf OR size, we get a rendered network back that has all nodes with the words leaf or size in their attributes/accessions (seen in ItemInfo), e.g., all publications, Traits with either word in them.

For leaf AND size, it should only have those nodes visible that have both words.

For "leaf size", it should be a phrase search, i.e., only shows nodes with the exact phrase in the attributes or accessions shown in Item Info.

Any other nodes connected to genes that do not contain the word or phrase should be hidden.

hope that explanation is clear. @mdonepudi @dicknetherlands
e.g., on the live Arabidopsis KnetMiner, we can see 3 varying networks where size of the rendered networks depends on OR or AND query, and should be even smaller for " " (phrase query):

https://knetminer.rothamsted.ac.uk/araknet/genepage?keyword=seed OR dormancy&list=MFT (click publications or phenotypes in network and ItemInfo shows either seed or dormancy highlighted); shows 18 (53) nodes.

https://knetminer.rothamsted.ac.uk/araknet/genepage?keyword=seed AND dormancy&list=MFT (click publications in network and ItemInfo shows either seed AND dormancy highlighted); only shows 8 (47) nodes now so smaller than OR search as it should be.

Note: ignore the + in queries/ url's in the above posts... What we really want is the OR, AND and phrase searches working via UI and API. @KeywanHP
I'll find some aratiny queries for you to test with too.

aratiny OXL had bugs with pre-set visible nodes and edges; now fixed in https://github.com/Rothamsted/knetminer/pull/387 ; for further testing "", OR and AND search.

https://github.com/Rothamsted/knetminer/commit/86ba5db37359d48020a3b71ca94633fcd2b0c216 looks to have fixed it.
But, would be good to know why using ### to replace quotes client-side and then re-adding quotes at the back-end fixed it and not just using url-encode for ", space, etc., and was it the encoding that was causing issues with space translated to + which threw Lucene search off?
Still for quotes, did url-encode not work instead of ### ?
just good for us to understand better. thanks @mdonepudi  @dicknetherlands

86ba5db looks to have fixed it.
But, would be good to know why using ### to replace quotes client-side and then re-adding quotes at the back-end fixed it and not just using url-encode for ", space, etc., and was it the encoding that was causing issues with space translated to + which threw Lucene search off?

When the whole keyword phrase is URL encoded (e.g "leaf size" ==> %22leaf%20size%22), it is producing results for leaf+size. Some kind of splitting happening based on Lucene operators AND,OR, + ?

thanks for explaining


Update example config, fixes #231

SImple lumped updates changed required parameters, but the example realization wasn't properly updated.  This updates the example config so it should run without issue.
Closes #231

Note #233 explains why the test is still failing.


Suggestion: Auto-kill onLoad and reverse

Hi, this is a great addon! Especially since this GDPR banner nagging allday
Here a suggestion: Add an option to enable it by default on every page onload, and add a key combination to undo this.

A PR to that effect would be welcome, but my suspicion is that it'd be too difficult to get right to be worth the effort. Essentially, the current "undo" for the plugin is to reload the page, and that allows for the "kill" action to just brute-force remove everything sticky. Enabling it to run at onLoad by default would require for the elements to be held in some memory, and to have some rather complex (and therefore failure-prone) logic driving their re-entry to the page.

See pr #2


Filtering entries in the stack selector is case sensitive

As opposed to the flat file driver, filtering entries in the stack selector is case sensitive. It should be case insensitive imo.

Add an entries field with a stack selector
Open the stack selector
Search for entry like 'home'. It won't work. You need to type 'Home'.

I've only noticed it for entries only as this is the only repository I use the Eloquent driver for.

I think this depends on the collation of your database (case insensitive or not). Do you know what yours is?

Nope :-). But nice pointer. I'll get back to this tonight. Curious!

Hopefully I’m right - from memory it’s that! If your collection has _ci in it it’s case insensitive which would mean I’m wrong!

So it seems when the data is in a JSON field MySQL carries out case sensitive comparisons as the data comes back in binary. The solution seem to be either to make column and value lowercase, or to cast the json_unquoted value as CHAR. Both of these feel like we would have to add mysql specific code to the base eloquent query builder.

I totally believe you 🤯😉

Another option would be to create a migration for your app that creates a generated column for title, and then MySQL will defer to using that in any queries:
<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return new class extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::table('entries', function (Blueprint $table) {
            $table->string('title')->storedAs('JSON_UNQUOTE(data->>"$.title")');
        });
    }
};

Wonderful! Thanks Ryan ❤.


You have listed matplotlib as a dependency

Hello
You have list matplotlib as a dependency, but it is not.
Regards

yes, i'll remove it
Le mar. 30 juin 2020 à 09:24, SignificantCell2<EMAIL_ADDRESS>a
écrit :

Hello
You have list matplotlib as a dependency, but it is not.
Regards
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Alpagateau/Bezier_Curve_animation/issues/1, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AMNCNN4VJZ52SLFZSVNZWF3RZGHJJANCNFSM4OL55TPA
.


expense sort & filter

1: add filter

[x] Billable
[x] Reimbursed
2: remove sort
[x] last modified time
3: add sort
[x] customer name
[x] paid through

issue closed


[BUG] Wrong database name when opening Sequel Ace with "Open Database Administration"

Describe the bug
When opening Sequel Ace with the 'DDEV: Open Database Administration' command the project name is used as the database name but the default DDEV database name is db which yields an Unknown database error.
ddev sequelace does the following:
open mysql://root:root@xyz.ddev.site:32782/db -a '/Applications/Sequel Ace.app/Contents/MacOS/Sequel Ace'
To Reproduce
Steps to reproduce the behavior:

"ddevManager.defaultDatabaseManager": "Sequel Ace"
Click on 'Open Database Administration'
See error

Expected behavior
Sequel Ace should be opened with database db by default or this should be configurable.
Screenshots
With 'DDEV: Open Database Administration'

With ddev sequelace

System:

OS: macOS 14.1.1
DDEV version: v1.22.5
Docker provider: Orbstack
VSCode version: 1.84.2
DDEV Manager version: v1.4.0

Hi. This is not related to this extension, the extension only runs DDEV commands, in this case ddev sequelpro it does not pass database names or any other configuration.
Please post the issue directly in the ddev repo.

Thanks for your reply but in the VSCode output console for DDEV I can see this when using 'Open Database Administration':
2023-11-30 08:17:02.731 [info] + open mysql://root:root@project_name.ddev.site:32791/project_name -a '/Applications/Sequel Ace.app/Contents/MacOS/Sequel Ace'
This happens with the following ddev commands in a terminal with the project folder as the current directory:
> ddev sequelace
+ open mysql://root:root@project_name.ddev.site:32791/db -a '/Applications/Sequel Ace.app/Contents/MacOS/Sequel Ace'
> ddev sequelace project_name
+ open mysql://root:root@project_name.ddev.site:32791/project_name -a '/Applications/Sequel Ace.app/Contents/MacOS/Sequel Ace'
Are you sure you're not adding the project name when calling ddev sequelace?
If not and this is a problem with ddev I would be glad to post an issue in the ddev repo but I'm not entirely sure what the bug description would be.

Ohh, i see what you mean, everything related to the database was moved to a new class to handle phpMyAdmin, Adminer and maybe some VS Code db extensions, in that new class the project name is added exacly as you mention.
I use Tableplus and never noticed this issue, checking the command's code, seems that the Tableplus command has the db name directly in the code (ignoring args) and the sequelace command uses the first arg (if provided) as database name.
I'll remove the project name from the command and publish an update this week.
Thank's for checking this.

Hi. An update has been published (1.4.2) please try it and let me know if it's working

It's working now. Thank you.

Glad to hear it's working correctly.


add check flag for CONFIG_NETFILTER_XT_MATCH_IPVS CONFIG_IP_VS_NFCT C…

add CONFIG_NETFILTER_XT_MATCH_IPVS , CONFIG_IP_VS_NFCT , CONFIG_IP_VS_RR kernel config check  in contrib/check-config.sh.
Signed-off-by: alexchen<EMAIL_ADDRESS>Replaces https://github.com/docker/docker/pull/26940

ping @mrjana @mavenugo @justincormack PTAL
also let me know if you want this to be added to 1.12.2; afaict there's no risk involved, so I'm fine with adding it if it makes it easier for you to debug issues

@thaJeztah Yes, let's add it into 1.12.2. LGTM

LGTM


skopeo showing duplicate layers

Hi, I've built an image with the imagebuilder tool. Base image has 3 layers and one is added by imagebuilder. docker inspect shows 4 layers as I would expect. But skopeo shows 11 layers:
$ skopeo inspect docker://docker-registry.example.com/aosqe/cucushift-base:latest
{
    "Name": "docker-registry.example.com/aosqe/cucushift-base",
    "Tag": "latest",
    "Digest": "sha256:57ba0882d5fb5722dbed7344dc7ec623c2a5b215fbc739d612ead990735dc51f",
    "RepoTags": [
        "latest"
    ],
    "Created": "2017-08-04T09:20:30.926379403Z",
    "DockerVersion": "1.13.1",
    "Labels": {
        "build-date": "20170705",
        "io.openshift.builder-version": "21ac267",
        "license": "GPLv2",
        "maintainer": "AOS QE Team",
        "name": "CentOS Base Image",
        "vendor": "Red Hat inc."
    },
    "Architecture": "amd64",
    "Os": "linux",
    "Layers": [
        "sha256:ff04a77efbee3d708c4ba5c379e00f72130a0477916d876673c7985660644523",
        "sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4",
        "sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4",
        "sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4",
        "sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4",
        "sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4",
        "sha256:f6d2db44e367d68f53eb090da638938427884404009636fdbe6d692ef382e410",
        "sha256:df685470456b4f944a37bf5492d610f296324cdfe7ca132e94751e06cdea8765",
        "sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4",
        "sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4",
        "sha256:15ddd396c8076103e6e61f304d21b54d47bcea914ef566b21850ee85c51463ee"
    ]
}

As you can see, there are a number of duplicate layers. But even if I count them as 1, then still layers are more than what docker shows.
Here's docker output for a reference:
$ sudo docker inspect docker-registry.example.com/aosqe/cucushift-base:latest
[
    {
        "Id": "sha256:8014a3aa6f2c3dbea5e1b74fa1ea0f4eccf9b82e3faa1429eafbc614745beaa3",
        "RepoTags": [
            "docker-registry.example.com/aosqe/cucushift-base:latest"
        ],
        "RepoDigests": [
            "docker-registry.example.com/aosqe/cucushift-base@sha256:57ba0882d5fb5722dbed7344dc7ec623c2a5b215fbc739d612ead990735dc51f"
        ],
        "Parent": "sha256:4e263fe1b294160435d005c0bc75f119fe45bfb76285020c3e52581e6e878a67",
        "Comment": "",
        "Created": "2017-08-04T09:20:30.926379403Z",
        "Container": "7aaed0a4378c5840ad5fc5620960e45936dc99951d690d6799a7607bd16d2b58",
        "ContainerConfig": {
            "Hostname": "7aaed0a4378c",
            "Domainname": "",
            "User": "root",
            "AttachStdin": false,
            "AttachStdout": false,
            "AttachStderr": false,
            "Tty": false,
            "OpenStdin": false,
            "StdinOnce": false,
            "Env": [
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
                "HOME=/home/jenkins"
            ],
            "Cmd": [
                "sleep 86400"
            ],
            "Image": "openshift/jenkins-slave-base-centos7",
            "Volumes": null,
            "WorkingDir": "",
            "Entrypoint": [
                "/bin/sh",
                "-c"
            ],
            "OnBuild": null,
            "Labels": {
                "build-date": "20170705",
                "io.openshift.builder-version": "21ac267",
                "license": "GPLv2",
                "name": "CentOS Base Image",
                "vendor": "CentOS"
            }
        },
        "DockerVersion": "1.13.1",
        "Author": "",
        "Config": {
            "Hostname": "d1e7c521d3a4",
            "Domainname": "",
            "User": "1001",
            "AttachStdin": false,
            "AttachStdout": false,
            "AttachStderr": false,
            "Tty": false,
            "OpenStdin": false,
            "StdinOnce": false,
            "Env": [
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
                "HOME=/home/jenkins"
            ],
            "Cmd": null,
            "ArgsEscaped": true,
            "Image": "",
            "Volumes": null,
            "WorkingDir": "",
            "Entrypoint": [
                "/usr/bin/scl",
                "enable",
                "rh-git29",
                "rh-ror42",
                "--",
                "/usr/local/bin/run-jnlp-client"
            ],
            "OnBuild": null,
            "Labels": {
                "build-date": "20170705",
                "io.openshift.builder-version": "21ac267",
                "license": "GPLv2",
                "maintainer": "AOS QE Team",
                "name": "CentOS Base Image",
                "vendor": "Red Hat inc."
            }
        },
        "Architecture": "amd64",
        "Os": "linux",
        "Size":<PHONE_NUMBER>,
        "VirtualSize":<PHONE_NUMBER>,
        "GraphDriver": {
            "Name": "overlay2",
            "Data": {
                "LowerDir": "/var/lib/docker/overlay2/2d1e874f5e43261a6a5f1e450f56dfb5cfcb343d9177b4177b0acd00dce0a6c0/diff:/var/lib/docker/overlay2/2ba6cbc2faa110b614d3b6c4746fbe65666d3f5e3aa472381335d1d1fdd3c012/diff:/var/lib/docker/overlay2/298feca6acd9aefde2ee3ba60c79a79cc0eb1425c60c57aacd96d33aad95a97a/diff",
                "MergedDir": "/var/lib/docker/overlay2/37087407e600c4da3c45ca4eed9d24b4eb56368e95fa15e60b20fba15ff2aed5/merged",
                "UpperDir": "/var/lib/docker/overlay2/37087407e600c4da3c45ca4eed9d24b4eb56368e95fa15e60b20fba15ff2aed5/diff",
                "WorkDir": "/var/lib/docker/overlay2/37087407e600c4da3c45ca4eed9d24b4eb56368e95fa15e60b20fba15ff2aed5/work"
            }
        },
        "RootFS": {
            "Type": "layers",
            "Layers": [
                "sha256:99b28d9413e47df267df84318788754dd39d4c8e0dc2c72c9e8922b3a91f21fa",
                "sha256:1420b3bd2231d58083b355d7f2286e901e035b0ccd69d8a68289993e4fb3fad5",
                "sha256:268371c1ff5c4c33086619c3d1e12bf72ede5a919a8e49331cecd5455fd49018",
                "sha256:dc9feeeb1b614a6947e3f004c8a647fbe13959fb2c158d175bd88bcbb4bf9cba"
            ]
        }
    }
]

Another interesting issue is that I can't match any of the skopeo layer hashes with those from docker.

/cc

Thanks for your report.
The a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4 layers are ”empty layer” entries, for things like CMD, ENV and similar Dockerfile entries. That layer is, though, physically a part of the image (e.g. it needs to be copied along with other layers), so it is not obvious that it should not be listed here.
Is it functionally important to you that skopeo should not be listing the layer, and if so, why? Or is it ”only” confusing? (I do realize that a confusing output may be problematic, just trying to figure out what the right thing to do is here…)

(If it matters, these empty layers are used only for schema1 images; an upgrade to a schema2 or OCI image generator and registry should make this go away.)

Hi, docker doesn't show these layers so it i confusing. On the other hand I don't mind having them there given that's documented somewhere.
Given the above explanation, I think the bigger issue is that I can't match layer hashes between docker and skopeo. How can this be explained and how could one correlate docker to skopeo inspect output?

I think the bigger issue is that I can't match layer hashes between docker and skopeo. How can this be explained and how could one correlate docker to skopeo inspect output?

Again, why does that matter? What are you ultimately trying to do? Are you building a content-addressable system of some kind? (Pedantically speaking, the answer is to filter out the a3ed…6d4 layer from the skopeo output; that should handle most, though not necessarily all, of the empty layers; but that’s not all that useful for deciding what skopeo should output.)

wrt empty layers - in my previous comment I said that I'm fine with them. It's good to be documented though for new users. My use case for this was to make sure my image is squashed before I push to repo. The additional layers shown by skopeo made me suspect something went wrong. I initially saw the base image had 4 layers during build and then see my new image has much more layers and I thought probably it was not squashed. Now I know what is the reason for them. Just telling why I was concerned.
wrt layers reported with different hash by docker and skopeo that is a big mystery for me. I was trying to compare locally running image to what is available in upstream repo. I guess the main image hash does the job as it is reported the same by both programs. I still can't understand though how could the two programs calculate the layer hashes differently. My thinking is that one of the programs should be doing it wrong. And it's better to understand which one, so this is fixed.

My use case for this was to make sure my image is squashed before I push to repo. The additional layers shown by skopeo made me suspect something went wrong.

Ah, that makes sense. The flip side is that atomic depends (?) on the layer list to know what to download, and it’s at least not immediately obvious to me that we can just skip the empty layers without breaking it.

wrt layers reported with different hash by docker and skopeo that is a big mystery for me.

skopeo inspect reports the digests of the compressed layer tarballs; docker inspect in RootFS.Layers shows the “DiffID”s, i.e. digests of the uncompressed layer tarballs:

The two are in general not the same
One uncompressed digest may map to several different compressed digests (depending on the specific implementation of the compression), so it is not possible to predict the compressed digest from the uncompressed tarball without having exactly the same compression implementation available
Without having access to the underlying tarball (compressed or uncompressed), knowing only the compressed/uncompressed digest, it is absolutely impossible to compute the corresponding uncompressed/compressed digest.
docker pull does not store the manifest with the compressed digest values locally; i.e. after the image is pulled, the layers are impossible to match against a remote repository, except by fetching the image from the remote repository and uncompressing the layers (in general), or by fetching the config which contains the DiffIDs (if the image is using schema2 or OCI).

Yeah, that makes the layer digests fairly difficult to work with.
https://github.com/containers/image/pull/288 and a few related PRs will allow skopeo to save the manifest when pulling the image, so that it is again available for reading using a containers/image, or skopeo, tooling; but that would still work better with a patched docker to save the same information also on docker pull. I’m working on that, but it will take a bit more time.

Thank you for explanation. Based on it I don't think we need to necessary fix anything in skopeo. Perhaps a few words in documentation about the data it is showing would suffice to make use aware about the meaning of the different hashes and difference from docker.

@akostadinov @mtrmac @vrothberg @TomSweeneyRedHat Does anyone know if the documentation was ever improved for this issue?

No doc changes for this that I"m aware of.

I’m tempted to say that explaining the difference between compressed/uncompressed digests (and manifest/config/manifest list digests) does not quite belong in the primary man pages.  Ordinary users don’t need to care, and explaining this in man pages would only confuse them, and people building specialized tools should know about all of these things… from… well… somewhere… yeah.
So, this should be explained, but I don’t quite know where.

Should we add a document to skopeo github to explain this then?

What will be confusing if there is a section in the man page about layers and digest? Especially becaues users may be exposed to the output from different tools about same images, such explanation will be valuable.

What will be confusing if there is a section in the man page about layers and digest?

I was basically thinking that either we put it in some appendix of one of the man pages (or to GitHub) where people who need this won’t notice, or we lead with the definitions in every affected subcommand, and all the people who don’t need to deal with this will have to read the document to realize they don’t need to deal with this.
But you’re right, adding a link to the DESCRIPTION section of skopeo-inspect(1) and podman-inspect(1) should work well enough; these are the two that matter the most (or have I missed an important subcommand?)

@mtrmac If you write up the description, I will add open PRs for podman, buidlah and Skopeo.

@mtrmac We never followed through on this.  Could you write up a description of the difference and we can add the description to skopeo-inspect and podman-inspect and we can close this issue?


Rendering root crumb

This library is fantastic and saved my team a ton of time.
Is there a way to display the root crumb by itself? ( '/' )
Currently it seems that if there is only one crumb the whole menu hides.

Hi, thanks for using. Current version of this library does't show root itself('/). If you need to show '/' try to wrap breadcrumbs in your own component and simple check url and conditionally show components.

@cvburgess If you need to display only a root breadcrumb you can do it like this
<Route path="/" render={props=>(   Whatever )}/>
If you mean that route breadcrumb is not displayed in a chain, I agree that this option needs more control, I will probably create a PR soon

@cvburgess , @roya3000 see PR #4

@octaharon, merged. Thank you for PR

Thank you @octaharon and @roya3000 - this is great work and appreciated!


fix: Bringing back navbar-stats test to E2E

Thank you for your contribution to the KodaDot NFT gallery.
👇 _ Let's make a quick check before the contribution.
PR type

[ ] Bugfix
[ ] Feature
[x] Refactoring

What's new?

[x] PR closes #3876
[ ] Requires deployment <rubick/magick_issue>
[x] quick fix

Before submitting Pull Request, please make sure:

[ ] My contribution builds clean without any errors or warnings
[ ] I've merged recent default branch -- main and I've no conflicts
[ ] I've tried to respect high code quality standards
[ ] I've didn't break any original functionality
[ ] I've posted a screenshot of demonstrated change in this PR

Optional

[ ] I've tested it at </rmrk/collection/26902bc2f7c20c546a-1FVG7>
[ ] I've tested PR on mobile and everything seems works
[ ] I found edge cases
[ ] I've written some unit tests 🧪

Had issue bounty label?

[ ] Fill up your KSM address: Payout

Community participation

[ ] Are you at KodaDot Discord?

Screenshot

[ ] My fix has changed something on UI; a screenshot is best to understand changes for others.

failing test not related with this PR but can it be solve here?

I'd rather leave it for another PR + issue:

https://github.com/kodadot/nft-gallery/issues/3966


Fix: Filtering works with group monitors (again)

⚠⚠⚠ Since we do not accept all types of pull requests and do not want to waste your time. Please be sure that you have read pull request rules:
https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#can-i-create-a-pull-request-for-uptime-kuma
Tick the checkbox if you understand [x]:

[x] I have read and understand the pull request rules.

Description
Fixes #3533

Remove the use of showPathName
send the filtering and sorting function as props to the listItem, and apply the filters inside
Group monitor itself bypass filtering if any of its children matches the filters

A key decision here is that if the filters apply to the group monitor itself but to none of its children, the children will not be shown. This is not a perfect choice but I think should be more practical in most uses.
Welcome to test more edge cases.
Type of change

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

Checklist

[x] My code follows the style guidelines of this project
[x] I ran ESLint and other linters for modified files
[x] I have performed a self-review of my own code and tested it
[x] I have commented my code, particularly in hard-to-understand areas
(including JSDoc for methods)
[x] My changes generate no new warnings
[ ] My code needed automated testing. I have added them (this is optional task)

Screenshots (if any)

match child

match group itself

Seems ok, will test in later e2e testing.


Still active?

Is this repo still maintained?

i guess not.
the dependencies here are so old... this project is not maintained.

True, and actually there are enough alternatives already existing

@mariomurrent-softwaresolutions do u have a recommendation for an alternative?

Hmm, actually not :( There are currently no alternatives