Add collected flag

Similar to the PR to BloodHound.py - https://github.com/dirkjanm/BloodHound.py/issues/138#issuecomment-1847589058
I've added a collected flag to satisfy the BloodHound CE Data Quality page
I also only add this flag if the domain SID has been resolved, otherwise I ended up with unwanted results as seen below:

This is also my first two lines of Rust code so feel free to change if the logic is incorrect!

Thanks @spyr0-sec :smiley: :100:  !


Inconsistency in navbar create dropdown

Gitea version (or commit ref): 1.9.0+dev-307-g43cf2f3b5
Git version: (not relevant)
Operating system: (docker on windows host, not relevant)
Database (use [x]):

[X] PostgreSQL
[ ] MySQL
[ ] MSSQL
[ ] SQLite

Can you reproduce the bug at https://try.gitea.io:

[X] Yes (provide example URL)
[ ] No
[ ] Not relevant

Log gist:

Description
Found some inconsistency regarding the user interface. In the navbar menu where you can create some repos etc. the hover highlight colour does not fit the list properly.
As you can see in the screenshot.
If found also out that this changes if you disable the element property underlined in the second screenshot. Then the result is as expected.
...
Screenshots

I also noticed this. I have no idea where this faulty inline style is coming from. I assume it is being added by JS, but my search so far did not yield any results.

I assume it is being added by JS, but my search so far did not yield any results.

My guess is that the JavaScript of SemanticUI does that.


Homeoffer button

Added Wlacz sie button on Homepage offer component

Codecov Report

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

@@           Coverage Diff           @@
##           master     #735   +/-   ##
=======================================
  Coverage   91.58%   91.58%
=======================================
  Files          89       89
  Lines        2673     2673
  Branches        5        5
=======================================
  Hits         2448     2448
  Misses        218      218
  Partials        7        7

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bc4f50a...fef33a7. Read the comment docs.

Blocked by #717


Ensure that we don't emit references to marker protocols in existential type metadata

Fixes rdar://88922030.

@swift-ci please test

@swift-ci please test

This issue is hard to trigger without also doing back-deployment, so I'm going to separate out the test.

@swift-ci please test and merge

@swift-ci please smoke test macOS

@swift-ci please smoke test Linux

@swift-ci please smoke test Windows


Add new PVs to S03

Some system tests (read_hardware_for_ispyb) have started failing because some new PVs which fgs connects to are not present:
TimeoutError: Failed to connect to all signals: fgs.synchrotron.machine_status.synchrotron_mode (CS-CS-MSTAT-01:MODE), fgs.synchrotron.machine_status.user_countdown (CS-CS-MSTAT-01:USERCOUNTDN), fgs.synchrotron.machine_status.beam_energy (CS-CS-MSTAT-01:BEAMENERGY), fgs.synchrotron.top_up.start_countdown (SR-CS-FILL-01:COUNTDOWN), fgs.synchrotron.top_up.end_countdown (SR-CS-FILL-01:ENDCOUNTDN), fgs.synchrotron.ring_current (SR-DI-DCCT-01:SIGNAL)

So this does work for me but that's because it's looking at the real PVs. S03 does have fake PVs but they're on BL03S-CS-CS..., which is hard to fit in given that there is no equivalent prefix for the real case. We will need to fix this when we do https://github.com/DiamondLightSource/python-artemis/issues/458 as then the test won't work against the real PV any more. I think the solution is to remove the additional prefix in S03


Promo Giveaway for Smart Contract

As an admin I would like to mint NFTs after the sale is over so that I can give these NFTs away for promotions.
We need to make sure that no other users are able to purchase these promotional NFTs reserved at the end of sale.
NFTs minted for promos will be automatically eliminated

Are we able to set the # of promotional pieces upfront? Though we typically want to reserve 5 pieces for promotions, we are going to know the actual qty to reserve before a drop is released.
A sellout scenario. For instance, we reserve 5 out 100 editions for promotion. Is the sale to the public going to be locked once the inventory reduces to 95?


try the effect of scikit-build

https://github.com/scikit-build/scikit-build

I think the first step would probably be to separate the library building from the swig generation, then we can maybe "just" use pyproject.toml nowadays after doing a proper build. This feedstock could produce libopenmeeg (which supplies the C++ so/dylib/DLL) and openmeeg (which would be a SWIG wrapper for it).
These ideas are in https://github.com/openmeeg/openmeeg/issues/449 and need to happen in the OpenMEEG repo first, so I don't think we need to keep an issue open here for them. Once they work there, it should be fairly easy to make a PR to do them here.


Feature Request: Auto Connect to current server

SQL Operations Studio Version: 0.26.7

When scripting an object, opening a script from file or creating a new script, I'd like it if SQLOps automatically connected to the current server.
Steps to Reproduce:
#1: Altering a stored procedure
Open Servers
Locate a stored procedure
Right-click, select 'Script as Alter'
Run Script - CONNECTION appears.
Would prefer if it assumed the same connection you opened it from.
#2. Opening a File or creating a new script
Open or create a script
Modify as needed
Press F5 to run - CONNECTION appears
Would prefer if it assumed the current connection.

I believe this is intended behavior and this is actually a regression.

The current behavior is "by design" though I agree the design is currently incorrect.
  The problem with auto-connecting when generating a create statement is that the entire statement will be highlighted as a syntax error as a duplicate database object.  In the Go to Definition scenario having the CREATE highlighted with the red squiggly seemed undesirable.
In the Script as Alter, Script as Execute, etc. the editor certainly should be connected.  We're currently thinking we'll update the behavior to connect for any scripting operation other than Script as Create.  I guess we could further refine this to only not connect in Go to Definition scripting and have the explicit Script as Create command connect assuming the typical scenario is to alter the CREATE statement and execute it on the current connection.

If you generate a CREATE script, could you not preface with a DROP [objecttype] IF EXISTS [objectname]? That would prevent the syntax error notification.

@barryseymour that's a good suggestion, thought I'm not sure we would want to add a drop statement into the Script as Create to avoid any user confusion or accidents.  SSMS has a separate Script Drop and Create which we could also consider.  I'll discuss a bit with our PM and try to figure out what makes the most sense here.  Thanks!


Add Nong Song:

Song Name
EGODEATH
Artist Name
david
Source
Direct file download
Youtube Link
No response
Direct File Link
https://soundcloud.com/saknol/egodeath-scrapped-megalo-replacement-idea
Song ID
951638
Start Offset [ms]
0
Extra
No response

accept


Unable to resolve a primary identifier for model 'x'

(This is a follow up investigation to https://github.com/prisma/prisma-client-js/issues/529)

Bug description

Some database tables return the following error on query:
PANIC: Unable to resolve a primary identifier for model <model-name>

How to reproduce

Import this SQL into a local MySQL database:
-- MySQL dump 10.13  Distrib 5.7.27, for osx10.14 (x86_64)
--
-- Host: <IP_ADDRESS>    Database: nextcloud
-- ------------------------------------------------------
-- Server version	5.7.29

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Table structure for table `jvMDv_collres_accesscache`
--

DROP TABLE IF EXISTS `jvMDv_collres_accesscache`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `jvMDv_collres_accesscache` (
  `user_id` varchar(64) COLLATE utf8mb4_bin NOT NULL,
  `collection_id` bigint(20) DEFAULT '0',
  `resource_type` varchar(64) COLLATE utf8mb4_bin DEFAULT '',
  `resource_id` varchar(64) COLLATE utf8mb4_bin DEFAULT '',
  `access` tinyint(1) NOT NULL DEFAULT '0',
  UNIQUE KEY `collres_unique_user` (`user_id`,`collection_id`,`resource_type`,`resource_id`),
  KEY `collres_user_res` (`user_id`,`resource_type`,`resource_id`),
  KEY `collres_user_coll` (`user_id`,`collection_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=COMPRESSED;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `jvMDv_collres_accesscache`
--

LOCK TABLES `jvMDv_collres_accesscache` WRITE;
/*!40000 ALTER TABLE `jvMDv_collres_accesscache` DISABLE KEYS */;
/*!40000 ALTER TABLE `jvMDv_collres_accesscache` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;

/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;

-- Dump completed on 2020-03-19 19:20:26

Introspect this database and run:
const { PrismaClient } = require('@prisma/client')

const prisma = new PrismaClient()

async function main() {
  const data = await prisma.jvMDv_collres_accesscache.findMany()
  console.log(data)
}

main()

Error:
(node:27332) UnhandledPromiseRejectionWarning: Error:
Invalid `prisma.jvMDv_collres_accesscache.findMany()` invocation in
/Users/divyendusingh/Documents/prisma/p2-nextcloud/r.js:6:55

PANIC: Unable to resolve a primary identifier for model jvMDv_collres_accesscache.
    at PrismaClientFetcher.request (/Users/divyendusingh/Documents/prisma/p2-nextcloud/node_modules/@prisma/client/runtime/index.js:1:48880)
    at processTicksAndRejections (internal/process/task_queues.js:85:5)
(node:27332) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:27332) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
Error in Prisma Client:
PANIC: Unable to resolve a primary identifier for model jvMDv_collres_accesscache. in
libs/prisma-models/src/model.rs:90:30

This is a non-recoverable error which probably happens when the Prisma Query Engine has a panic.
Please create an issue in https://github.com/prisma/prisma-client-js describing the last Prisma Client query you called.

Expected behavior

It should work or fail gracefully
Prisma information

Prisma CLI Version<EMAIL_ADDRESS>Current platform     : darwin
Query Engine         : prisma 6aa23a61c78a5418a0231347458d639aa337ec1d (at /Users/divyendusingh/Documents/prisma/p2-nextcloud/node_modules/prisma2/query-engine-darwin)
Migration Engine     : migration-engine-cli 6aa23a61c78a5418a0231347458d639aa337ec1d (at /Users/divyendusingh/Documents/prisma/p2-nextcloud/node_modules/prisma2/migration-engine-darwin)
Introspection Engine : introspection-core 6aa23a61c78a5418a0231347458d639aa337ec1d (at /Users/divyendusingh/Documents/prisma/p2-nextcloud/node_modules/prisma2/introspection-engine-darwin)

Environment & setup

OS: Mac OS Catalina
Database: MySQL (but applies to others)

Simpler reproduction:
CREATE TABLE IF NOT EXISTS `foo` (
  `one` int(11) DEFAULT NULL,
  `two` int(11) DEFAULT NULL,
  UNIQUE KEY `Index 1` (`one`,`two`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

model foo {
  one Int?
  two Int?

  @@unique([one, two], name: "Index 1")
}

const { PrismaClient } = require('@prisma/client')

const prisma = new PrismaClient()

async function main() {
  const data = await prisma.foo.findMany()
  console.log(data)
}

main()

Invalid `prisma.foo.findMany()` invocation in
C:\Users\Jan\Documents\throwaway\587\index.js:6:33

PANIC: Unable to resolve a primary identifier for model foo.
    at PrismaClientFetcher.request (C:\Users\Jan\Documents\throwaway\587\node_modules\@prisma\client\runtime\index.js:1:48880)
    at processTicksAndRejections (internal/process/task_queues.js:85:5)
(node:32884) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:32884) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
Error in Prisma Client:
PANIC: Unable to resolve a primary identifier for model foo. in
libs/prisma-models/src/model.rs:90:30

This is a non-recoverable error which probably happens when the Prisma Query Engine has a panic.
Please create an issue in https://github.com/prisma/prisma-client-js describing the last Prisma Client query you called.

Seems to have to do with the NULL of the columns, not reproducible for:
CREATE TABLE IF NOT EXISTS `foo` (
  `one` int(11) NOT NULL,
  `two` int(11) NOT NULL,
  UNIQUE KEY `Index 1` (`one`,`two`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

which is
model foo {
  one Int
  two Int

  @@unique([one, two], name: "Index 1")
}

This is currently a concious limitation, that we need to work around with a guardrail: https://github.com/prisma/prisma2/issues/1880

This is still reproducible with:
divyendusingh [p2-587]$ yarn prisma2 --version
yarn run v1.21.1
$ /Users/divyendusingh/Documents/prisma/p2-587/node_modules/.bin/prisma2 --version
@prisma/cli          : 2.0.0-alpha.990
Current platform     : darwin
Query Engine         : prisma 2accb9c7eacdc984874eaeb63377fe705dfd3203 (at /Users/divyendusingh/Documents/prisma/p2-587/node_modules/@prisma/cli/query-engine-darwin)
Migration Engine     : migration-engine-cli 2accb9c7eacdc984874eaeb63377fe705dfd3203 (at /Users/divyendusingh/Documents/prisma/p2-587/node_modules/@prisma/cli/migration-engine-darwin)
Introspection Engine : introspection-core 2accb9c7eacdc984874eaeb63377fe705dfd3203 (at /Users/divyendusingh/Documents/prisma/p2-587/node_modules/@prisma/cli/introspection-engine-darwin)
✨  Done in 0.79s.

Closing this in favor of https://github.com/prisma/prisma-client-js/issues/529, they represent the same thing.

This is now fixed by aligning the unique criteria the engines accept. All fields need to be not null.


make pyproject.toml compatible with Pypi

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (8225bac) 96.93% compared to head (9e3b90c) 96.93%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main      #18   +/-   ##
=======================================
  Coverage   96.93%   96.93%
=======================================
  Files           8        8
  Lines        1109     1109
=======================================
  Hits         1075     1075
  Misses         34       34

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


Major enhancements

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

This PR is included in version 2.0.0 :tada:


Storage Key Connection string in all demos & instructions

The blade showing the access keys with keys and connection strings have been updated.
Anywhere in the demos and lab instructions, the three ellipses have been removed. The student can now copy the connection string by pressing the copy button.

I just noticed this myself. This great simplifies the instructions.


upgrade instructions result in deleting people and projects

When I follow the upgrade instructions:
rm Puppetfile.lock Gemfile.lock
bundle install --no-deployment --without development --path .bundle
bundle exec librarian-puppet install --clean

My modules/people and modules/projects folders are removed / deleted. This let to a serious amount of stress today. :)
I'm not a Puppet expert, but I think it happens when you run librarian-puppet after removing the Puppetfile.lock
How are we supposed to handle this?

This was also my experience and my inelegant solution was to put my modules/people and modules/projects changes in another branch or my repository. Obviously, I'd like to know how this is supposed to work...

@jbcpollak @tcooper I've never seen this. Can you reproduce it and post the steps here?

This is strange behavior. As pointed out above, the top-level modules/ is for your personal or project manifests. Boxen modules are all in shared/.
Are any of you modifying Boxen aside from Puppetfile or creating manifests? Trying to understand what's different about your Boxens.

Before the last time I updated our-boxen I tucked my personal modules away for safe keeping. The update removed them so I created a branch to store them in and have been running boxen out of the branch since then and haven't updated our-boxen since then because of the problem. When I get a chance I'll merge my branch to master and update to see if the problem can still be reproduced.

Sounds good. I'm going to close this for now, but if you discover it to still be an issue feel free to re-open.

This happened to me again, on a brand new Mac after upgrading following the instructions in the faq.
I am not 100% sure what happened, but here is what I did:

checked out my master 'our-boxen', where everything is fine
make a branch
merged current upstream our-boxen into our branch
resolved conflicts
At this point I'm reasonably confident our changes were still in place
ran bundle commands
ran ./script/boxen
Had problems (#740, #741)
Resolved those problems by manually editing Puppetfile and hacking a file in modules
ran ./script/boxen
At this point, boxen ran cleanly, except I noticed our customized people and projects changes were not applied.

This is the 3rd time I've had this happen, whenever I follow the upgrade instructions.

I followed the update instructions in the FAQ (https://github.com/boxen/our-boxen/blob/master/docs/faq.md) with the one exception of using a local branch rather than master. The files were not deleted.
I suspect the files end up deleted after the first run of ./scripts/boxen after following the upgrade instructions, but I have no idea how boxen works, so I'm not sure if that is a reasonable guess or not.

What files were deleted, exactly?
On Thu, Apr 30, 2015 at 9:28 PM Joshua Chaitin-Pollak <
<EMAIL_ADDRESS>wrote:

I followed the update instructions in the FAQ (
https://github.com/boxen/our-boxen/blob/master/docs/faq.md) with the one
exception of using a local branch rather than master. The files were not
deleted.
I suspect the files end up deleted after the first run of ./scripts/boxen
after following the upgrade instructions, but I have no idea how boxen
works, so I'm not sure if that is a reasonable guess or not.
—
Reply to this email directly or view it on GitHub
https://github.com/boxen/our-boxen/issues/717#issuecomment-98040727.

It appears to be modules/people and modules/projects. I don't think
anything else is affected.

@jbcpollak is your boxen repo publicly accessible? I can't imagine any way this could happen.

I can give you access, there isn't anything  sensitive in the repo, but it
does reference some private repos I can't share.
On May 3, 2015 6:27 PM, "Sean Knox"<EMAIL_ADDRESS>wrote:

@jbcpollak https://github.com/jbcpollak is your boxen repo publicly
accessible? I can't imagine any way this could happen.
—
Reply to this email directly or view it on GitHub
https://github.com/boxen/our-boxen/issues/717#issuecomment-98551077.

this is caused by bundle exec librarian-puppet install --clean. The --clean option means delete any file/folder not being managed by librarian-puppet, thus Puppetfile.
You should not use the --clean if you have files not checked into your repo.
Thanks

Thanks. Going to close this, would appreciate a PR to update documentation
if folks think that would be helpful.
On Sun, May 24, 2015 at 1:12 PM Salimane Adjao Moustapha <
<EMAIL_ADDRESS>wrote:

this is caused by bundle exec librarian-puppet install --clean. The
--clean option means delete any file/folder not being managed by
librarian-puppet, thus Puppetfile.
You should not use the --clean if you have files not checked into your
repo.
Thanks
—
Reply to this email directly or view it on GitHub
https://github.com/boxen/our-boxen/issues/717#issuecomment-105058561.

I have the same problem. My repo https://github.com/stereobooster/my-boxen

So I never residences, but I think the probably I had was because of a bad
merge. At some point I merged my master branch with upstream master by
doing a rebase of my changes on top of the upstream master. But maybe I had
some other funky merges before or after that.
Anyway, I cleaned everything up, I think by starting from scratch and
reapplying all of my changes (by cherry picking).
Now when I merge upstream master into my branch, I don't have this problem
anymore.
Also, I noticed my old private matter branch had a lot of committed content
in the modules folder which I don't think upstream master has. After I
fixed the merge, my modules folder is much cleaner.
I'm writing this from my phone and I can't check my repo right now, but I'm
reasonable sure a rebooted merge will help.
On Mon, Jul 20, 2015, 3:20 PM stereobooster<EMAIL_ADDRESS>wrote:

I have the same problem. My repo https://github.com/stereobooster/my-boxen
—
Reply to this email directly or view it on GitHub
https://github.com/boxen/our-boxen/issues/717#issuecomment-122995580.

--
Joshua Chaitin-Pollak
Chief Technology Officer
Assured Labor, Inc.
www.assuredlabor.com
www.empleolisto.com.mx
www.trabalhoja.com.br

https://github.com/rodjek/librarian-puppet

Librarian-puppet manages your modules/ directory for you based on your Puppetfile. Your Puppetfile becomes the authoritative source for what modules you require and at what version, tag or branch.

bundle exec librarian-puppet install does not remove modules/people and modules/projects, but it still adds folders to module projects

Figured it out. The problem occurs when you working outside of default location.
I was editing in /Users/name/my/my-boxen.
When you working in default directory (/opt/boxen/repo) everything is back to normal.

That makes sense, before I shifted my boxen merge around, I has a
~/src/my-boxen directory, but one I finished the merge changes I started
just symlinking /opt/boxen/repo to ~/src
On Mon, Jul 20, 2015, 5:37 PM stereobooster<EMAIL_ADDRESS>wrote:

Figured it out. The problem occurs when you working outside of default
location.
I was editing in /Users/name/my/my-boxen.
When you working in default directory (/opt/boxen/repo) everything is
back to normal.
—
Reply to this email directly or view it on GitHub
https://github.com/boxen/our-boxen/issues/717#issuecomment-123051139.

--
Joshua Chaitin-Pollak
Chief Technology Officer
Assured Labor, Inc.
www.assuredlabor.com
www.empleolisto.com.mx
www.trabalhoja.com.br

Same issue here, no matter if i merge into a local branch or master, or if i'm working in the default dir or not.
modules/ gets cleared and filled with modules that apparently should go to shared/
My repo: fculpo/boxen

Got the same problem.
Cloned this repo, added modules/people/* and modules/projects/*, updated Gemfile according to docs  (for boxen 2.8.0 to add OSX 10.11 support) and then my modules/ folder was truncated and filled with dependencies.

Same result here. The only thing that is different is an update to El Capitan.


RSS Media

What about rss media parsing?
I didn't see how I can get thumbnail from RSSFeedItem.
You can research this spec: http://www.rssboard.org/media-rss
items for test:
testRss.txt

Thanks. And I have a question. How I can get item XML value? Maybe your library have some private method? I want to try parse image from current XML.

What element or attribute exactly are you trying to get? Does it belong to the spec, or is it contained XML data within an Element?
See if #14 helps

@nmdias I mean that "media" is element of feed item. "media" can has many optional attributes. I try to use "media:thumbnail". But another users maybe need to use other attributes.

@damienissa you can't at this time. Currently, FeedKit doesn't support the Media namespace, so there aren't any private methods or properties that would allow you to read them.
I'll make sure to include this feature in the 6.0.0 release.

The RSS Media Namespace is now available in the master branch. It will also be available in the future 6.0.0 release.


Adding border to blockquote when printing

When I print the PDF the border shadow is suppressed on blockquotes in Chrome.  Could you add a 1px line on the right and left of the blockquote image when printing?  Or Chrome specific css ?
Additional Details
http://homebrewery.naturalcrit.com/print/Hkp2IAvPg

Yeah, Chrome has a bug where they simply haven't implemented printing CSS shadows. There is a workaround in progress though and I think it was planned for the version 3.0 release.

Here's the styling you can add if you want to try it out before the release. This also adds shadows to the monster stat blocks. It works by embedding the shadows directly into the artwork of the box borders.

That does it.  Someone should probably put together a collection of these CSS and HTML tricks.


Add Retryable HTTP Client

Describe the solution you'd like
Currently Ratify’s built in ORAS store, does not utilize request back off retries when sending requests to registry. The server can receive multiple concurrent requests to validate images from the same registry or multiple images from the same registry in the same request. This can cause the # of simultaneous requests to the registry to the exceed the registry threshold leading to 429s returned. Ratify should use a retry-able http client with ORAS-go to help alleviate the issue.
Environment:

Ratify version: (use the image tag): Ratify v1.0.0-beta.2
Kubernetes version: (use kubectl version): 1.25.4

/cc @shizhMSFT

oras-go will implement a default retry mechanism in its version 2.0.0 release as being discussed in https://github.com/oras-project/oras-go/discussions/232.
Besides, oras-go also supports 3rd party retry-able HTTP client such as github.com/hashicorp/go-retryablehttp. Here's the example code of how to integrate go-retryablehttp with oras-go/v2/registry/remote/auth.Client:
retryClient := retryablehttp.NewClient()
retryClient.RetryMax = 10

authClient := &auth.Client{
    Client: retryClient.StandardClient()
}

// use `authClient` for registry access

Since ratify is dealing with lots of 429s, it is suggested to configure retry with jitters.
To be more scalable, ratify may consider caching or other mechanisms to reduce the request rate to a single registry.


ci: Fix incorrect DLL version on release

The release workflow publishes the correct nuget version, but doesn't update the DLL file version. For example Parse 3.0.0 on nuget downloads the Parse.dll with version code 2.0.0. The DLL file is correct, but it's version is not updated correctly. That means the nuget installs the correct Parse.dll file, just the file itself shows an incorrect version, so we won't unpublish the nuget version 3.0.0.

🎉 This change has been released in version 3.0.1


Encrypted rooms cannot send message

Latest matrix-nio release, latest pantalaimon compiled from git (because your latest release has been broken for the last 12 or so months!). I have tried a few different configurations, but using git release of pantalaimon and latest stable release of matrix-nio seems to have least amount of problems. Reading encrypted rooms works fine. Sending and reading in unencrypted rooms works fine. Whenever I try to send a message to an encrypted room, I get a few "Missing session for device XXXXXXX" but nothing else until my client times out.

Forgot to mention: Using pantalaimon 0.10.5 with matrix-nio 0.19.0 can send messages in some encrypted rooms, but half the unencrypted and encrypted rooms will not work and i get an error from pantalaimon telling me it failed to sync. Additionally, if I start using pantalaimon with the matrix-nio 0.19.0, the device it creates on my account is not an encrypted one and so it won't work. Creating the session with an up to date matrix-nio and then downgrading it afterward resolves this. Using an up to date matrix-nio with pantalaimon 0.10.5 breaks media, as you know I'm sure.

I have the same problem. Do you know how to fix it?

I have the same problem. Do you know how to fix it?

Not a full fix, but here is the hacky solution I am happy with:
--- a/pantalaimon/daemon.py     2024-01-19 17:17:10.010235297 +0000
+++ b/pantalaimon/daemon.py     2024-01-19 17:17:21.477075027 +0000
@@ -940,8 +940,7 @@
         # Don't encrypt reactions for now - they are weird and clients
         # need to support them like this.
         # TODO: Fix when MSC1849 is fully supported by clients.
-        if request.match_info["event_type"] == "m.reaction":
-            encrypt = False
+        encrypt = False

         msgtype = request.match_info["event_type"]

I am using Gentoo, so I just placed this file in /etc/portage/patches/dev-python/pantalaimon/disable_encryption.patch and reinstalled it. This will disable encryption for all outgoing messages. Me personally, I don't mind doing this.


[Mobile]  keepStyleOnNewLine is true, cannot copy and paste

My issue is about [Mobile]
keepStyleOnNewLine is true, text content cannot copy and paste

Can you provide a more detailed explanation of your current situation?


Label mode uses invalid characters for specifying days

I Label mode, the way to define what days a pod can be killed is by using a comma separated list:
mon,tue,wed,thu,fri

https://github.com/bloomberg/powerfulseal/blob/master/LABELS.md
Commas however are not allowed by the Kubernetes spec in label values:
https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
Valid label values must be 63 characters or less and must be empty or begin and end with an alphanumeric character ([a-z0-9A-Z]) with dashes (-), underscores (_), dots (.), and alphanumerics between.

Would is make sense to change the separator, or add support for an additional one, maybe -, _ or .?
Currently trying to set the label as specified in the example will simply fail.

Great catch. I think that the cleanest would probably be to use dashes instead. What do you reckon @benceszikora ?

The easy fix would be to switch to dashes, I agree. In an ideal world however, all of these would be annotations I think. The character set allowed there is much more forgiving.
That's a much bigger change though looking at the code, so not sure what your thoughts are on that?

Actually, supporting annotations would be pretty straightforward. It would require:

Adding a new field in the pod class in https://github.com/bloomberg/powerfulseal/blob/f5b9364fd66482f9d003223dafbc4ebadef66a1c/powerfulseal/k8s/pod.py#L24-L36

Populating that field when reading from kubernetes in https://github.com/bloomberg/powerfulseal/blob/f5b9364fd66482f9d003223dafbc4ebadef66a1c/powerfulseal/k8s/k8s_inventory.py#L105-L117

Change the 6 occurrences of direct access to pod.labels like this one https://github.com/bloomberg/powerfulseal/blob/f5b9364fd66482f9d003223dafbc4ebadef66a1c/powerfulseal/policy/label_runner.py#L122 to use a new method instead, which looks into either labels (for backwards compatibility) or annotations.

Also, step 1) and 2) are actually optional, because the annotations will already be accessible in pod.meta.metadata.annotations, but they would make the code cleaner.

@seeker89 I created #217 for this, let me know what you think!


Add Palantir Foundry connector docs page

Hi Power Query team, this is Mike from the Palantir team owning the Power Query connector for Foundry. It exists in the "List of Power Query Connectors" page already, but this PR adds a proper docs page.
Thanks in advance for your review.

@mshafer25
Thank you for your contribution. Would you take a moment to sign the Contributor License Agreement (CLA)? After the CLA is signed, someone can review your pull request. Thanks!
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

@microsoft-github-policy-service agree company="Palantir"

@bezhan-msft, @DougKlopfenstein
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.

@bezhan-msft thanks for your review, I've updated the content per your suggestions and responded to your question above

#sign-off


Implement bodyElement in Tooltips and Popover

Tether added bodyElement option in 1.4.0 (see https://github.com/HubSpot/tether/pull/204) and it would be better to use bodyElement instead of trying to do the same thing with container option
in Tooltip (https://github.com/twbs/bootstrap/blob/v4-dev/js/src/tooltip.js#L284-L288) which doesn't work because Tether previous version only add element to the <body>
It would be usefull for #22249

.

I guess this is related to the problem I'm facing right now : I can't make a popover to be appended to a specific DOM element. It's always added to the body.
When I comment the Tether code (and only that part of the code) in the Tooltip.prototype.show function, the tooltip is obviously not well positioned but is appended to the DOM element I ask.
Any idea for a workaround ? ;)

Closed and fixed by #22444


Fix language in documentation referring to txn retries

Fixes #1117

This change is

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/fa9a7a1af8ec73ce9aaaee67ce765bc8a657f3e0/

Thanks for making these updates, @spencerkimball! Almost everything looks good, but I'm still confused about some language around increasing transaction priority in transactions.md. Can you help clarify for me?

Review status: 0 of 12 files reviewed at latest revision, 2 unresolved discussions.

transactions.md, line 9 at r1 (raw file):

CockroachDB supports bundling multiple SQL statements into a single all-or-nothing transaction. Each transaction guarantees [ACID semantics](https://en.wikipedia.org/wiki/ACID) spanning arbitrary tables and rows, even when data is distributed. If a transaction succeeds, all mutations are applied together with virtual simultaneity. If any part of a transaction fails, the entire transaction is aborted, and the database is left unchanged. CockroachDB guarantees that while a transaction is pending, it is isolated from other concurrent transactions with either snapshot or serializable [isolation levels](#isolation-levels).

{{site.data.alerts.callout_info}}For a detailed discussion of CockroachDB transaction semantics, see How CockroachDB Does Distributed Atomic Transactions and Serializable, Lockless, Distributed: Isolation in CockroachDB.{{site.data.alerts.end}} Note that the explanation of the transaction model described in this blog post is slightly out of date. See the [Transaction Retries](#transaction-retries) section for more details.

nit: Put this new note on a new line, unless you want it to be part of the alert; in that case, it should be placed before {{site.data.alerts.end}}.

transactions.md, line 197 at r1 (raw file):

~~~

{{site.data.alerts.callout_info}}When two transactions contend for the same resources indirectly, they may create a dependency cycle leading to a deadlock situation, where both transactions are waiting on each other to finish. In these cases, CockroachDB allows the transaction with higher priority to abort the other, which must retry. On retry, the transaction inherits the higher priority. This means that each retry makes a transaction more likely to succeed in the event it again experiences deadlock.{{site.data.alerts.end}}

I think I'm missing something. Here and in a few other places, we say that the transaction with the higher priority aborts the other transaction. But isn't it now the case that the transaction accessing the resource first locks it, which causes the contending transaction to abort and retry?

Comments from Reviewable

Let me know if there's still confusion in the document itself, of if you were just confused about the abort behavior with the new model.

Review status: 0 of 12 files reviewed at latest revision, 2 unresolved discussions.

transactions.md, line 9 at r1 (raw file):
Previously, jseldess wrote…
nit: Put this new note on a new line, unless you want it to be part of the alert; in that case, it should be placed before {{site.data.alerts.end}}.

Done.

transactions.md, line 197 at r1 (raw file):
Previously, jseldess wrote…
I think I'm missing something. Here and in a few other places, we say that the transaction with the higher priority aborts the other transaction. But isn't it now the case that the transaction accessing the resource first locks it, which causes the contending transaction to abort and retry?

We no longer abort and retry just because another transaction has locked a resource. We instead wait for the resource to be unlocked and then proceed.

Comments from Reviewable

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/175291065859b3941471a1b7418d1c2d3dad8c42/

Thanks for the clarification, Spencer. I think there's still confusion in the document itself. Specifically, there's still a lot of emphasis on retries and priorities, which, for me at least, distorts the picture a bit. Here are some ideas:

It would help to expand the intro to briefly mention conflicts, that we lock and have the contending transaction wait until the resource is free unless there's deadlock, in which case we abort, increase priority, and retry.
Perhaps we need a new section, before the content about retries and priorities, explaining how we handle contention normally. This would give context to the retry and priorities sections.
We may also need to reframe the retry and priority content itself a little to make sure it's clear that we retry and increase priority only when there's deadlock.

Thoughts? If you prefer, I could work on this in a follow-up PR.

Review status: 0 of 12 files reviewed at latest revision, 2 unresolved discussions.

Comments from Reviewable

Review status: 0 of 12 files reviewed at latest revision, 7 unresolved discussions.

begin-transaction.md, line 9 at r2 (raw file):

The `BEGIN` [statement](sql-statements.html) initiates a [transaction](transactions.html), which either successfully executes all of the statements it contains or none at all.

{{site.data.alerts.callout_danger}}When using transactions, your application should include logic to retry transactions that are aborted to break a dependency cycle between concurrent transactions leading to deadlock.{{site.data.alerts.end}}

You have to retry for read/write contention, not just deadlocks.

frequently-asked-questions.md, line 109 at r2 (raw file):

[Transactions](transactions.html) in CockroachDB do not explicitly lock all of their data resources. Instead, using [optimistic concurrency control (OCC)](https://en.wikipedia.org/wiki/Optimistic_concurrency_control), CockroachDB proceeds with transactions under the assumption that there’s no contention until commit time. In cases without contention, this results in higher performance than explicit locking would allow. With contention, transactions may need to be retried.

In practice, most applications experience low contention. However, with significant contention, OCC may perform poorly. If your application experiences high rates of contention, snapshot isolation (SI) can significantly improve performance by eliminating the possibility of retries (except in cases of deadlock).

Is deadlock really the only reason SI transactions can be restarted? I think there's still ReadWithinUncertaintyInterval and a few other things (like coordinator restarts)

transactions.md, line 7 at r2 (raw file):

---

CockroachDB supports bundling multiple SQL statements into a single all-or-nothing transaction. Each transaction guarantees [ACID semantics](https://en.wikipedia.org/wiki/ACID) spanning arbitrary tables and rows, even when data is distributed. If a transaction succeeds, all mutations are applied together with virtual simultaneity. If any part of a transaction fails, the entire transaction is aborted, and the database is left unchanged. CockroachDB guarantees that while a transaction is pending, it is isolated from other concurrent transactions with either snapshot or serializable [isolation levels](#isolation-levels).

"with either snapshot or serializable isolation levels" sounds like there are other isolation levels that don't provide this isolation. I think I'd remove this clause, or reword it to make it more clear that you're providing a definition of "isolation" instead of qualifying "other transactions".

transactions.md, line 68 at r2 (raw file):

## Transaction Retries

Transactions in CockroachDB lock data resources which are written during their execution. In the event that a pending write from one transaction conflicts with a read or a write of a concurrent transaction, then the concurrent transaction must wait for the earlier transaction to complete before proceeding. CockroachDB implements a distributed deadlock detection algorithm to discover dependency cycles. Deadlocks are resolved by allowing transactions with higher priority to abort their dependencies. Transactions which are aborted to avoid deadlock must be retried.

s/read or a write/write/

transactions.md, line 70 at r2 (raw file):

Transactions in CockroachDB lock data resources which are written during their execution. In the event that a pending write from one transaction conflicts with a read or a write of a concurrent transaction, then the concurrent transaction must wait for the earlier transaction to complete before proceeding. CockroachDB implements a distributed deadlock detection algorithm to discover dependency cycles. Deadlocks are resolved by allowing transactions with higher priority to abort their dependencies. Transactions which are aborted to avoid deadlock must be retried.

Transactions executed with the serializable isolation level may also require retries if they experience read/write contention with other concurrent transactions, though this is limited to a single retry. Note that these types of transaction retries do not occur for transactions executing with the snapshot isolation level. Consider using snapshot isolation if your use case has high contention and your clients are retrying frequently. See [Isolation Levels](#isolation-levels) for more details.

How is this limited to a single retry?

Comments from Reviewable

Sounds like you're going to take over this PR. I'll address Ben's comments in Reviewable here.

Review status: 0 of 12 files reviewed at latest revision, 7 unresolved discussions.

begin-transaction.md, line 9 at r2 (raw file):
Previously, bdarnell (Ben Darnell) wrote…
You have to retry for read/write contention, not just deadlocks.

Yes, let's make this less specific by not mentioning deadlocks.

frequently-asked-questions.md, line 109 at r2 (raw file):
Previously, bdarnell (Ben Darnell) wrote…
Is deadlock really the only reason SI transactions can be restarted? I think there's still ReadWithinUncertaintyInterval and a few other things (like coordinator restarts)

You're right. Both of those will cause restarts.

transactions.md, line 7 at r2 (raw file):
Previously, bdarnell (Ben Darnell) wrote…
"with either snapshot or serializable isolation levels" sounds like there are other isolation levels that don't provide this isolation. I think I'd remove this clause, or reword it to make it more clear that you're providing a definition of "isolation" instead of qualifying "other transactions".

Might as well remove that extra verbiage.

transactions.md, line 70 at r2 (raw file):
Previously, bdarnell (Ben Darnell) wrote…
How is this limited to a single retry?

It's not when you include uncertainty restarts or txn coordinators dying. I originally specified that you could still have retries if on the retry we write different keys, but dropped that detail because it felt unnecessarily pedantic. Because there are other ways things should restart, we should just drop the "single retry" detail.

Comments from Reviewable

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/14b999f2b41aca82df457f8fccaca6481aafd7e9/

Review status: 0 of 12 files reviewed at latest revision, 5 unresolved discussions.

begin-transaction.md, line 9 at r2 (raw file):
Previously, spencerkimball (Spencer Kimball) wrote…
Yes, let's make this less specific by not mentioning deadlocks.

Done.

frequently-asked-questions.md, line 109 at r2 (raw file):
Previously, spencerkimball (Spencer Kimball) wrote…
You're right. Both of those will cause restarts.

@bdarnell, I don't understand the two addition causes you mention. Can you propose updated language here?

transactions.md, line 7 at r2 (raw file):
Previously, spencerkimball (Spencer Kimball) wrote…
Might as well remove that extra verbiage.

Done.

transactions.md, line 68 at r2 (raw file):
Previously, bdarnell (Ben Darnell) wrote…
s/read or a write/write/

Done.

transactions.md, line 70 at r2 (raw file):
Previously, spencerkimball (Spencer Kimball) wrote…
It's not when you include uncertainty restarts or txn coordinators dying. I originally specified that you could still have retries if on the retry we write different keys, but dropped that detail because it felt unnecessarily pedantic. Because there are other ways things should restart, we should just drop the "single retry" detail.

Done.

Comments from Reviewable

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/54dd0bbc3c14cb8a5f799568f1f0dfd397bebbf8/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/e083579cf4c45d72b462c5e5525538466f049b3b/

Reviewed 12 of 12 files at r3.
Review status: all files reviewed at latest revision, 5 unresolved discussions.

frequently-asked-questions.md, line 109 at r2 (raw file):
Previously, jseldess wrote…
@bdarnell, I don't understand the two addition causes you mention. Can you propose updated language here?

After chatting with @bdarnell, since it's misleading to use "lock-free", I'm just going to remove this question from the FAQ. We already touch transactions in "Do transactions in CockroachDB guarantee ACID semantics?" and "Does CockroachDB support distributed transactions?".

Comments from Reviewable

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/92c1cf77d3bc22fcbda1c8d58b2faf82ee4a0cd3/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/94be3298f83b3bcda653be030b2f135f0b34fa5d/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/94be3298f83b3bcda653be030b2f135f0b34fa5d/


Broadcasting a list of infected persons is not GDPR conform

Describe the bug
The whole concept of this server is to store a list of infected COVID19 persons and send it to everyone.
I know that the list is supposed to be anonym, but locally you can match the IDs to a person. Even a beginner software developer will be able to modify the mobile app (Open Source and API are a good thing, but they are transparent and you can modify them) and store GPS and timestamp with the key and you don't have to upload the new app to the Store, so Google will not be able to check this. When the list of infected COVID19 patients (or their Ids or Keys even if you encrypt everything 100 times) is sent to the server the new app will be able to find out where and when it detected the infected person. If such a modified app is then distributed you can even create a whole database of keys.
This huge data privacy leak was already metioned on the DP3T paper:
https://github.com/DP-3T/documents/blob/master/DP3T White Paper.pdf
"Infected individuals. The centralised and decentralised contact tracing systems share the
inherent privacy limitation that they can be exploited by an eavesdropper to learn whether an
individual user got infected and by a tech-savvy user to reveal which individuals in their
contact list might be infected now. However, the centralised design does not allow proactive
and retroactive linkage attacks by tech-savvy users to learn which contacts are infected
because the server never reveals the EphID s of infected users."
The so called "retroactive linkage attacks by tech-savvy users" is a huge problem!
Furthemore the whole thing is not GDPR conform and is not conform to the EU recommendations:
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32020H0518&from=EN
(16) | With particular regard the use of  COVID-19 mobile warning and prevention applications, the following  principles should be observed:                                                                                (1)  safeguards ensuring  respect for fundamental rights and prevention of stigmatization, in  particular applicable rules governing protection of personal data and  confidentiality of communications;                                                                                (4)  effective cybersecurity requirements to protect the availability, authenticity integrity, and confidentiality of data;                                                                                (5)  the expiration of  measures taken and the deletion of personal data obtained through these  measures when the pandemic is declared to be under control, at the  latest;                                                                                (6) uploading of proximity  data in case of a confirmed infection and appropriate methods of warning  persons who have been in close contact with the infected person, who  shall remain anonymous; and                                                                                (7)  transparency requirements on the privacy settings to ensure trust into the applications.
To Reproduce
Steps to reproduce the behavior:
Broadcasting of the Keys
Expected behavior
No Broadcasting of infected Keys combined with Open Source and Open APIs.
Screenshots
Desktop (please complete the following information):
All OSs, all versions.
Smartphone (please complete the following information):
All Smartphones.
Additional context
Major data privacy leak.

/kind privacy
Please see the overall project page hosted at https://www.google.com/covid19/exposurenotifications/
In particular the FAQ and additional Terms of Service to utilize the on-device APIs.

If the app is Open Source a person can change it and use the modified app, this person (tech-savvy) will not comply to your ToS. If he does not use your store, you will not be able to notice he has a different app.

And the EU recommedation says you have to take measures to prevent it. A ToS will not do the job.

Hi @Covid19Fighter - thank you for taking the time to open an issue and provide feedback. The server does not store information about a specific person or device. We've gone to extensive lengths (which you can audit in this codebase) to make the server unable to associate a particular exposure key to a device or person. In addition to the standard Apple AppStore and Google Play Store review processes, apps must individually be added to an allowlist to use this API. The server is configured to validate against side-loaded APKs, mitigating a vector you've described.
You can read more about our architecture in Server Functional Requirements.
For legal questions, please see our FAQ and additional Terms of Service at https://www.google.com/covid19/exposurenotifications/, which specify which devices can utilize the on-device APIs, as well as what other APIs may be used in conjunction with the APIs (Term 3.c). If you have additional questions, please feel free to contact us at the email in the bottom of the README. Thank you and have a great day!

Thank you for the fast answer.
I do not find any info on the allowlist verification. How those the allowlist verification check that the app was not modified? They are open source, you can change the code.

Those answers are available in our FAQ, linked at the bottom of https://www.google.com/covid19/exposurenotifications/.

Sorry, not finding the right sentence. Could you please quote?

Section 10. How will apps get approval to use this system? in our FAQ linked at the bottom of https://www.google.com/covid19/exposurenotifications/

Ok, the guys that create the app will sign this and be approved. But they will publish the app as Open Source on a git. So anyone can modify this app and create a new one. So, how are you making sure this does not happen?

Hi @Covid19Fighter it's possible for people of any gender to create an app. Usually these apps will be developed by public health authorities (PHAs) or people working closely with PHAs. There's no requirement that implementers make their application open source. If someone were to modify the app and create a new one, that would be a different app that would need to go through an approval process to get added to the Apple App Store or Google Play Store.

Ok, so if they publish it as Open Source (like in Germany) and someone creates a modification and does not publish it by the Stores and propagates it as apk download, they could get the keys and combine them with additional information. Right?

The code for the client or server application being open source is inconsequential to whether someone can make a custom app. Getting a user to install such an app would require them to enable installation from unknown sources.

Sorry I do not understand the point. The user is the one that wants to deciphers the keys (hacker). He knows his sources.

I think you have a major attack vector here.

Can you be more specific about which keys you mean?

The keys of the infected persons you are broadcasting.

Let me back up to add clarity that might help answer your query. The allowlist is both a client-side and server-side allowlist. In order for an app to access the client API (SDK), it needs to be added to an allowlist. In order for that same app to publish keys to a server, it needs to be in the allowlist for the server.
If someone were to take an existing app implementation and sideload it, they would not be able to access the client-side API (SDK) without being added to the allowlist.

Ok, but if it copies the app it will have the same identity as the original app. Or not?

no, it will not.

The temporary exposure keys that are sent to devices are only ever made available in large batches over a sufficiently large geographic area. There isn't anything to decipher, the keys are available for distribution to all mobile devices participating in the protocol.
If someone were to try and tamper with those exports, the file would fail to validate the signature as signed by the server and would be rejected by the operating system for import and matching.

The user is not tampering with them, the user is only reading them and comparing them to the list of keys stored locally as the original app does. The only change on the software would be to store other information (i.e. timestamp) additionally to the information received from bluetooth). If you know when you met the infected users you can find out who they were.

The modified app cannot do this comparison because it doesn't have the root TTKs nor does it have access to the derived keys.

But the original app is comparing also the keys to find who is infected, and gets true or false. So the modified app will do the same and only look when it got the key that is now broadcasted as infected. If the original app can, the new should also be able to do this.

 It was mentioned on the DP-3T whitepaper by the professors. I thought you may have found a solution to this problem.

"However, the centralised design does not allow proactive
and retroactive linkage attacks by tech-savvy users to learn which contacts are infected"

The app is not responsible for comparing the keys, nor does any app have access to the derived keys that have been collected over BLE.
I would encourage you to read more of the documents from https://www.google.com/covid19/exposurenotifications/
In particular the items under

Exposure Notifications Bluetooth Specification
Exposure Notifications Cryptography Specification
Exposure Notifications Android API Documentation

Not deep linking because those documents could have new versions published at any time.

Ok, I already went through documentation, but I am not finding any place that stops "proactive
and retroactive linkage attacks by tech-savvy users". Maybe it is solved, but this only seems possible if most of the logic is done under the app on the OS side (not open) and the app is only a kind of a mask.

The documentation is not extensive enough to be sure.

By the way, measuring distance with Bluetooth doesn't sound physically possible. Do you have studies on this?

Hi @Covid19Fighter - this repository is for a sample server implementation. If you have specific questions about BLE, we're likely not the right group of people to answer them.
Are you able to describe a "proactive and retroactive linkage attacks by tech-savvy users"? I believe we've responded to all your concerns in previous comments.

Hi @sethvargo , thanks for your previous answers, they confirm my understanding of security aspects of Exposure Notification API. Further question on this topic: it seems that based on published cryptographic and Bluetooth specification it's possible to write implementation of Exposure Notification API from scratch - meaning that it'd be possible to "enrich" it's output with some additional data. We can imagine that this modified implementation would be attaching timestamp and GPS position to each received RPI, and then instead of processing RPIs and TEKs in batch (producing just aggregate result) it would output which RPI matched with some TEK (meaning we'd know when and where contact with infected person happened).
Do you see a risk in this kind of "enriched" API implementation being developed?

Hi @kbobrowski thanks for your question. It's unlikely such an app/server implementation would pass the allowlisting requirements from the Google/Apple app stores. Our security and privacy team have gone to extensive lengths to remove the ability to associate a particular TEK to a device/person in our implementations. You can actually look at the closed issues history on this repository to see their feedback. Part of the reason we're developing the server in the open is so folks can inspect the privacy preserving aspects we've implemented.

@sethvargo thanks, I'm sure that this kind of modified app (with re-implemented Exposure Notification API) won't appear in Play store, I had in mind situation where adversary might distribute APK. In this case I think safety would depend on whether country-specific application properly implemented SafetyNet for fetching TEK, and whether TEKs are handled properly on the device (not only in Google's layer, but also in country-specific layer on top), such that they cannot be revealed. I don't doubt that it's impossible to associate particular TEK to a person, I'm more worried about a situation where someone may acquire TEKs and timestamped / geolocated RPIs (since the latter is openly transmitted by Bluetooth), and would be able to infer when / where some contact with infected person took place.

Hi @kbobrowski - we've done our best to think through the various attack vectors. If you're able to reproduce an attack (or have an idea of how one might work), feel free to reach out to us confidentially at the email address in the README of this repo.

@sethvargo The point @Covid19Fighter was making has been published e.g. in this paper as "Nerd attack" (see also https://github.com/corona-warn-app/cwa-documentation/issues/102#issuecomment-631045106)
Personally, I don't see an issue with this: The "Nerd" would need to be a close contact of the infected person to be able to retrospectively identify them from e.g. timestamped GPS data, and I believe that most users who are willing to warn others about their infection through an app also make their identity known to their close contacts, through other means than this server.

@mh- I am meeting a lot of people I am not a close contact. Most of business people do.
@sethvargo - Again, the idea of broadcasting critical medical data to millions of devices is against all data protection and hacker recommendations. You can put 100 of layers of encryptions, rotate the keys, you will still get not one but hundreds of vectors. I think you got the whole decentralized idea wrong. Decentralized storage is good but decentralized matching is bad because of the broadcasting of critical data. No one on his rigth mind would do this with credit card data. It would be much easier to secure a centralized server that does not store the requests.

Hi @Covid19Fighter - this repository is for a sample server implementation. If you have specific questions about BLE, we're likely not the right group of people to answer them.

Please, I would be glad to discuss BLE with the rigth group of people. Getting distance out of RSSI measure on a dynamical environment does not seem easy or even possible to me. This again, is a well known fact.

@ all: Please do not think I am a kind of conspiracy person or even against a tracing app. I think to use technology to trace COVID19 is one of the most important tasks rigth now. But if you use broadcasting of critical information as communication against all data privacy concepts and BLE for distance measuring against every study published on this I am afraid we are loosing precious time here.

Hi @Covid19Fighter - I believe we've addressed all of your feedback from previous comments. I kindly as that you please take some time to read our published information on https://www.google.com/covid19/exposurenotifications/. Many of the concerns you've addressed are mitigated or are not present in the design of this system.

We are not "broadcasting all the critical medical data to millions of devices". The information is random identifiers. This data isn't akin to "credit card data" as mentioned in your comment, since they are anonymous IDs.

As far as I know, none of the maintainers are lawyers, so we can't address your GDPR concerns directly. However, our legal and policy teams have reviewed the design and architecture of the system. You can view the additional Terms of Service at https://www.google.com/covid19/exposurenotifications/.

Asking people to disclose potential security vulnerabilities confidentially is an industry best practice. Otherwise every report could become a zero-day attack without giving maintainers a time to patch. Some companies leverage third-party services like HackerOne, but we're choosing to use email for now. I apologize if that appears "unopen" as that is not our intention.

You can find a reference implementation of an Android application [here])(https://github.com/google/exposure-notifications-android).

What steps would you like us to take to bring this issue to resolution?

@sethvargo - Thank you very much for the answer, I appreciate your effort. I think I need to look at more specific documentation. It is unclear for me at which level you perform the key matching. If it is at a level you can access only from the OS and you secure the OS or if it something you can actually do at the app. It is also unclear how the infected key data is transported and stored locally and how the local received keys are stored locally (does the app have access to them or is it simply using some piece of logic buried deep on the OS). Without this information the leak possibilities are too large and I cannot analyze it. Again, I think broadcasting information that can be matched locally and can allow this kind of attack by nature is not a good practice. You can mitigate (and you try it hard), but not heal such a conceptional problem and I think it is a conceptional problem and not a physical problem because you try to match the data at the mobile device only to avoid sending the local data to a secure server as normal applications do and the result is that you broadcast critical data to millions of devices. Maybe if you publish more detailed info it helps. I will send you also my e-mail if you want to send me some information not disclosed here. If I understand everything I will close the ticket. I think I am able to understand it if it is well explained, I am trying and I should be able because even if I am no hacker I have a master in telecommunications engineering.

@sethvargo Thank you for your effort. I still the concept of broadcasting the critical data is still wrong and it makes an attack to easy, because you get the IDs also locally by Bluetooth, so you can alway find a way to match them. Sending it to millions of devices and do it with Open Source software makes is here more dangerous. Yo can mitigate this main problem and do you try hard with the encryption and the playing and changing keys but it is only a mitigation. I think you noticed it and this is why you are forbbiding GPS features to run in parallel, it stays a very dangerous practice and in my opinion not apt for any kind of critical information. How good your mitigation depends a lot at which level the data is stored, transported and handled and how secure this layers are. OS will be more sure than the app, but again I have not enough documentation to tell. I think you are right on discussing this issues on a more private way if the system is online, but it is not yet and you should fix all security issues before going live. I sent you an e-mail, maybe you can send me more detailed documentation. I also would like to speak to the people in charge of the BLE, I know MIT was working on this. It is not really something you can solve easily. You have two different antennas, you only know one, you don't really know your environment (walls, ground, ...) and it could by changing (walk), the persons could hand the devices on their hands, pockets, put them on a table. The distance(RSSI) equation depends a lot on all these factors. I have some ideas, but it seems almost impossible. A lot of studies on this.

@Covid19Fighter I think you don't understand how the process of whitelisting apps works. The fact that code source of each application will be published as an Open Source doensn't mean that anyone can modify this code and compile it as the same approved application. Every app is signed with a proper certificate. This certificate belongs to each Health Authority and SHOULD NOT BE PUBLISHED. So everybody can build the open sourced code but need to sign it with his own certificate. This certificate needs to be added to the whitelist by Google&Apple and app needs to be reviewed by them. So it will not be as easy as you think.
Another thing is that while risk calculation app owner has no access to RPIs of matched contacts - the API returns only general information - how many matched 'devices' you have, what is the calculated risk for each of them (based on your as an app owner risk calculation configuration), how long was the match (but even for longer 'meeting' app owner can read only up to 30minutes match in 5minuters interval) etc.
Also you as an app owner has NO ACCESS to scanned RPIs so you don't know that app has detected new RPI and add 'GPS and timestamp' to such event.

@pkleczko - Thank you! This seems to make some sense from the security side. It indeed mitigates the problem further. Sorry but I did not find any place giving such exact definition of the process.
If the app has a certificate and the certificate is whitelisted and you check at runtime this certificate everytime you may close some of the major vectors, you can try to simulate the whitelist authority but I assume this again is certified so it gets more complicated. If the App has no access to the RPIs and this is done by the OS you close some other possibilities. This is what I was asking. You still can access the BLE with the Libraries on an additional app (or are they closing BLE for any other app?) and check for devices and try to get a list, if they do not modify the BLE protocol (which does not seem possible) you should be able to read the RPIs without the API. If the OS is also storing the broadcasted RPIs of infected persons and handles them encrypted at all times (storage, memory and CPU) it gets more difficult. I mean, trying to secure this amount of data over this amount of devices using different hardware and OS is kind of impossible, but you are trying very hard. I still do not understand why you are doing it this way. It is not the usual way to do this and again it is not GDPR conform.

Hi folks - I'm going to close this issue.
I believe the questions that have been asked have been answered. As @sethvargo pointed out in a previous comment. None of us are accredited lawyers in the EU and we cannot comment on GDPR conference.
As of right now, Google and Apple are NOT running this server. We are providing it to governments and public health authorities to run.
If you have a concrete reason that you believe this work does not conform to GDPR, please send an email to the address in the main README.md file and we will route it to the appropriate people.
/close


Store time of tagging

Resolves #111

@Krastanov , any idea what the xvfb startup issue is from(the documentation ci failure)? https://github.com/QuantumSavory/QuantumSavory.jl/actions/runs/8932976512/job/24537665495?pr=114#step:7:564

Same GLFW error here as https://github.com/QuantumSavory/QuantumSavory.jl/pull/107#issuecomment-2093927326

is this ready for review?

Yes, sorry my bad, I should've re-requested for review

no worries! You might have said so in person, but it helps to have it mentioned here as well in case I forget

This seems nearly ready.
I think we are still missing tests for the new functionality, though. Tests that previously would have failed, like requesting filo or fifo for a whole register where we have various slots of the register tagged in arbitrary order. Could you add such tests?

It looks to me like these tests that we already have are what you described?
https://github.com/Abhishek-1Bhatt/QuantumSavory.jl/blob/f606f1baa76236d48bcbdc1065f208ff6628e2df/test/test_tags_and_queries.jl#L74-L100

I made some changes and polish. Please check each of the commits I have submitted in case something is off. Most of them have a clear description for why I added them. Those marked fixup are just there to fix silly mistakes I have made as I was working on this.

woohoo, this is in!


Optimize store.set entity validation

If the entity that comes from the mapping is already valid, avoid going to the DB at all. Also add a metrics section for as_modifications, since some DB accesses shift from store_set to as_modifications. Part of #1381.
PR for grafana https://github.com/graphprotocol/instrumentation/pull/3.

This looks good, but you should also change the lookup that happens in EntityCache from looking up missing entities one by one to using a bulk query (EntityQuery with a EntityFilter::In) and then put the entities you get back or None into self.current.

@leoyvens Were you able to measure the impact of this change compared to before?

@Jannis I only observed that store.set now takes less time than as_modifications, as expected. I want to do the bulk loading as well and then I'll measure.

@leoyvens Works for me!


QUICK-FIX Fix comments notification styling

@zidarsk8 There are 3 things that I need to mention:

If no checkboxes are checked then system will send emails to all by default. If this is true, then we don't need checkbox on Enable notifications on comments. It can be label like everything else.
I see that comment notifications exist only for Assessments. Initial request was to have it on Assessments, Requests and cycle Tasks. If this is changed then everything is ok, but if isn't, then we are missing notifications on Requests and cycle Tasks.
Since I've removed checkbox from Enable notifications on comments label, please adjust your code and remove redundant stuff for this.

Let me know if you have any questions.

@vladan-m This PR does nothing i asked for. And is not what the spec asks for.

@zidarsk8 Then the specs are changed. Send me URL of the specs

@vladan-m The specs did not change. it is still the same file as before.


ISPN-6798 Examples of JDBC CacheStore configuration should remind about the sha…

…red attribute.
https://issues.jboss.org/browse/ISPN-6798

thanks @ryanemerson ! merged


Disable cluster autoscaler in spec (temporarily until we have one again)

As long as we have no cluster autoscaler supporting our machine controller, we should not mislead the users and make clear we have none.

We decided to wait and sync with @hardikdr and @prashanth26 about when the integration of cluster-autoscaler will come. If it takes too long and we still want to not confuse the users we should rather change the dashboard (cc @grolu @holgerkoser @petersutter) by only allowing to enter a fixed number of worker nodes per pool (the dashboard should write the provided to number both autoScalerMin and autoScalerMax).

Closing as cluster-autoscaler is merged (#200).


Cause game to crash

Hello, not exactly related to the tweak, but new update of Uma Musume cannot launch with the tweak enabled.

同


(Auto-)Purge Contacts/Locations in Contact Diary

Current Implementation
You can add contacts and locations and manually delete each of them.
Suggested Enhancement
It should be possible to purge or auto-purge contacts/locations that haven't been contacted in the last 14 days.
Expected Benefits
Much less clutter.

Related Issues:

#322
#405

@nohn
Your request seems to be a duplicate of my request https://github.com/corona-warn-app/cwa-wishlist/issues/405. Please check it out. If you think your needs are covered by #405 you can add any additional comments there and close this one.

Correct. Duplicate of #405


chore: migrate few APIs to brige API model

Description
why ?
what ?

Migrate remaining 10 APIs in CustomActionCollectionRepositoryCEImp.java to the Bridge API model .

fixes #31990
Automation
/ok-to-test tags=""
:mag: Cypress test results

[!CAUTION]
If you modify the content in this section, you are likely to disrupt the CI result for your PR.

Summary by CodeRabbit

Refactor

Enhanced query construction and readability in server operations by introducing a new abstraction for building queries.

@sumitsum I guess this also will break the EE flow. Do we have a PR ready to address the ee side?

Merging this into chore/31943_migrate_action_coll_repo_3 dev branch to take the changes together to release.


Issue 89 point 32 original project issue 716

Hi,
very small pr to fix the point number 32 of issue #89, matching the issue 716 in the original project
It is just a dependency version change.
Regards.

Sorry wrong repo


Error 型に対してメッセージがログファイルに出力されない問題を修正

Codecov Report
Base: 69.57% // Head: 69.57% // Increases project coverage by +0.00% :tada:

Coverage data is based on head (bd68828) compared to base (4a8583a).
Patch coverage: 60.00% of modified lines in pull request are covered.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #314   +/-   ##
=======================================
  Coverage   69.57%   69.57%
=======================================
  Files          65       65
  Lines       12135    12139    +4
  Branches     1617     1618    +1
=======================================
+ Hits         8443     8446    +3
  Misses       2097     2097
- Partials     1595     1596    +1

Impacted Files
Coverage Δ

src/helpers/string.ts
36.84% <60.00%> (+10.17%)
:arrow_up:

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

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


vscode.languages.getDiagnostics do not return tags for faded out errors

Version: 1.33.0-insider
Commit: 0ac111466ec925fd5ca180ab9893f51531e419b2
Date: 2019-04-01T15:47:22.304Z
Electron: 3.1.6
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Darwin x64 18.2.0
Related: https://github.com/Microsoft/vscode/issues/51104
Repro:

Clone this repo (unused-bug branch) https://github.com/octref/hello-code/tree/unused-bug

yarn install && yarn watch

F5 to debug

Open a JS file with following content:
const foo = 5

export const bar = 10

Run command Hello World

Returned diagnostics do not include tags. Heres' the output

[
  {
    "severity": "Warning",
    "message": "'foo' is declared but its value is never read.",
    "range": [
      {
        "line": 0,
        "character": 6
      },
      {
        "line": 0,
        "character": 9
      }
    ],
    "source": "ts",
    "code": 6133
  }
]

This makes it impossible for me to write end-to-end test for unused variables: https://travis-ci.org/vuejs/vetur/jobs/514281703#L572-L575.
Also I'm curious — why in the inspector I get serverity: 1 but in the JSON.stringify conversion it becomes Warning?

fyi @jrieken @dbaeumer

Returned diagnostics do not include tags. Heres' the output

That only means it's not part of being json-stringified. We have never made promises about that. Why aren't you using the object as defined by its API?


Polish Repo

Codecov Report

Merging #10 (b91aae9) into main (e46714c) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #10   +/-   ##
=======================================
  Coverage   88.88%   88.88%
=======================================
  Files           9        9
  Lines         333      333
=======================================
  Hits          296      296
  Misses         37       37

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


ci: Add GOPATH to binary build job & fix setup-go action.

Fixes add_binaries job

Codecov Report

Merging #139 (536aab0) into main (57f45aa) will increase coverage by 0.72%.
The diff coverage is 51.78%.

@@            Coverage Diff             @@
##             main     #139      +/-   ##
==========================================
+ Coverage   46.10%   46.82%   +0.72%
==========================================
  Files          33       33
  Lines        2757     3248     +491
==========================================
+ Hits         1271     1521     +250
- Misses       1374     1615     +241
  Partials      112      112

Flag
Coverage Δ

unittests
46.82% <51.78%> (+0.72%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pkg/plugins/events/dev/eventing.go
0.00% <0.00%> (ø)

pkg/plugins/queue/dev/queue.go
41.88% <21.05%> (-12.17%)
:arrow_down:

pkg/plugins/queue/sqs/sqs.go
56.91% <42.85%> (-5.21%)
:arrow_down:

pkg/plugins/events/sns/sns.go
57.60% <44.82%> (-3.27%)
:arrow_down:

pkg/plugins/queue/pubsub/pubsub.go
57.61% <45.33%> (-3.17%)
:arrow_down:

pkg/plugins/storage/s3/s3.go
53.03% <48.21%> (-5.60%)
:arrow_down:

pkg/plugins/events/pubsub/pubsub.go
58.20% <54.54%> (-4.06%)
:arrow_down:

pkg/plugins/secret/dev/dev.go
77.00% <62.50%> (-3.27%)
:arrow_down:

pkg/plugins/storage/storage/storage.go
63.28% <65.51%> (+2.03%)
:arrow_up:

pkg/plugins/document/document.go
77.93% <66.66%> (-1.16%)
:arrow_down:

... and 5 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7f5775a...536aab0. Read the comment docs.


Tobin gh91 descriptor set cb invalid

Fixes #91
I believe this completes the remaining cases where CB_INVALID was not correctly handled.
This PR handles descriptor sets and all of their bound sampler/image/buffer resources.
Added tests to verify command buffer set to invalid for destruction of bound descriptor set and descriptor set buffer/image/sampler resources.
A key for descriptor sets and their bound resources is to only consider the active set/bindings combinations at draw time. This means that a cmd buffer only goes invalid when resources that it's using are destroyed.

cherry-picked and pushed to master

:+1:


fix build

Pull Request Test Coverage Report for Build<PHONE_NUMBER>5
Details

0 of 3 (0.0%)  changed or added relevant lines in 1 file are covered.
365 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.7%) to 6.165%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/lib.rs
0
3
0.0%

Files with Coverage Reduction
New Missed Lines
%

src/lib.rs
365
3.97%

Totals

Change from base Build<PHONE_NUMBER>7:
-0.7%

Covered Lines:
59

Relevant Lines:
957

💛  - Coveralls


nginx-ingress-controller: support for oauth2_proxy

I'd like to have an nginx-ingress-controller that that works with https://github.com/bitly/oauth2_proxy,
It looks like this will require more than surface level changes to nginx-ingress-controller. I'm curious if this is something that is worth accommodating in this "upstream" nginx-ingress-controller or if it would be invasive enough to not be desired?
I'm just starting to look into this but it seems like it would requiring:

augmenting the nginx template to accept other chunks of config for configuring oauth2_proxy
alternatively, modifying it to optionally accept another ConfigMap that contains the nginx template so users could do arbitrary other config changes while still benefiting from the rest of the nginx-ingress-controller machinery
needs to consume a Secret to set relevant env vars or flags for oauth2_proxy (the oauth client_secret)

The idea here is to be able to deploy Ingress along with kube-lego (for SSL to protect auth info/cookies) and then have oauth2_proxy configured  to accept users for a certain Azure Active Directory tenant or to a GitHub organization so that I can automatically give my coworkers access to cluster service while keeping others out.
I suppose this could also be done as an extra hop, with another nginx with oauth2_proxy sitting infront of the ingress nginx Pods but that seems a bit less clean.
I'm curious if anyone else is interested in this, and if it makes sense to be part of the upstream nginx-ingress-controller or if its more appropriate as a separate project?

alternatively, modifying it to optionally accept another ConfigMap that contains the nginx template so users could do arbitrary other config changes while still benefiting from the rest of the nginx-ingress-controller machinery

This is possible now. Check the custom-nginx-template section

@colemickens this is similar to this request https://github.com/kubernetes/contrib/issues/1327

@colemickens what if instead of adding this code inside the controller we use auth_request  to delegate the authentication to an external service/url?

That's a good point. If oauth2_proxy runs as a normal Service/Deployment then we would just need a way to configure auth_request to point to the oauth2_proxy Service. That seems remarkably straight forward actually.

need a way to configure auth_request to point to the oauth2_proxy Service

What about a global configuration and an annotation like ipwhitelist? This allows the semantic "all the services require authentication" and "this ingress requires authentication" (the annotation overrides the global value, to allow a different auth service)

I took a look at the ipwhitelist and I understand how I could implement a similar annotation for the auth_request field. I would like to take a crack at this tonight or in the next few days.
However, I'm not sure I understood this portion:

This allows the semantic "all the services require authentication" and/or "this ingress requires authentication" (the annotation overrides the global value, to allow a different auth service)

Are you saying that I could read the annotations off of the Ingress object for the global nginx config and could then read annotations from the individual services to allow auth to be applied to only a portion of the Ingress (and/or to override the global nginx config)?

However, I'm not sure I understood this portion:

Sorry about that.
You can add a global option like WhitelistSourceRange  and an annotation in the Ingress rules.
This allows authentication to all the ingress rules in the controller or just in the ingress with the annotation (the annotation always overrides the global value).

@colemickens just in case a couple of day I started with this here
After merging my pending PRs my plan is to continue with this

Thinking about picking this up again. Looks like you copied the directory of one of the other extension/annotations and started adding in the annotations for auth_request. Can you give me a brief rundown on the 4 annotations and how they differ so I can continue on the same path you were headed down?

@colemickens tomorrow this will be working (1796)

Can you give me a brief rundown on the 4 annotations...

Only the annotation ingress.kubernetes.io/auth-url is required

Oh wow, cool, thank you!

@colemickens were you able to get  nginx-ingress-controller + oauth2_proxy working w/ the ingress.kubernetes.io/auth-url?  If so, could you post a gist of your ingress def?

@rtluckie, how did you tried this? I'm sitting here waiting for 0.8.4 release, though it will be included only there :)

@aledbf, is there a chance to see this released anytime soon?

@colemickens : What values did you provide to interact with oauth2_proxy? Do you have samples of the deployments/services of oauth2_proxy and how it's references in the ingress resource?

I'm sorry, I never got this into a complete/documented state.

To be honest, I don't know if there was an updated container published, per @kop's question.


chore(main): release 1.1.1

:robot: I have created a release beep boop
1.1.1 (2024-10-10)
Bug Fixes

temp removing bruno (6667e5d)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v1.1.1
:sunflower:


[Marketplace]: Add dropdown icon for 'Add app' button and align dropdown values with button width

EPAM AI DIAL chat version
0.18.0
How to reproduce
Steps:

click on "DIAL Marketplace" button
click "My applications" button on side panel
click on "+ Add app" button

Actual result
Drop down with options Custom app and Quick app opened

Expected result

Replace + in the button to dropdown arrow
Align width of dropdown values with 'Add app' button's width

https://www.figma.com/design/lwL5jneveZczAj5RLcLFH2/DIAL-Chat?node-id=11654-53700&node-type=frame&t=frDzDhvFlhGwzze5-0
Confidential information

[X] I confirm that do not share any confidential information

Verified on staging env successfully.

If to enable Custom applications, Disable Quick applications => there is + Add app button, if to click on it 'Add custom application' opens
If to enable Quick applications, Disable Custom applications => there is + Add app button, if to click on it 'Add quick application' opens

If to enable both features => there is Add app with arrow, if to click on it there are two options 'Custom App' and 'Quick App'


CNDB-9967 re-enable = operator for analyzed SAI

The operator was disabled by #702 as it may produce surprising matches. For backward compatibility, we allow this behavior.

Thank you guys!


Build of develop fails

Build of develop branch fails:

core/core.go:55: too many arguments in call to cmd.UnmarshalBinary

Indeed.
Package core isn't currently tested, most parts are generated but still, we should add some tests about the part that are written by humans, otherwise typos like this one will sneak in again without being identified neither by Travis nor by Coveralls.

Nothing wrong with develop. Most likely this is a problem with submodules or local dependencies.
You can run the following in a clean machine (docker run --rm -it golang) to verify that develop builds correctly:
git clone --recursive https://github.com/TheThingsNetwork/ttn.git $GOPATH/src/github.com/TheThingsNetwork/ttn
cd $GOPATH/src/github.com/TheThingsNetwork/ttn
make deps
make build

I do agree with @KtorZ that we could add tests to the core package.


VSCode "problems" menu entries are too eager to disappear

rust-analyzer version: nightly (4998807)
I don't use the cargo check on save, preferring to run it manually from time to time.
My expected workflow: run cargo check RA runnable, get problems menu filled, go over each and fix the issues one by one, sometimes navigating other code or switching between issues without any changes.
My current workflow: same, but with the direct cargo check cli output, because problems disappear for me even if I simply navigate between them.
Reproduction on rust-analyzer repo:
spoil the name of the trait
https://github.com/rust-analyzer/rust-analyzer/blob/479d1f7eec22c3564867223e2093f14774092528/crates/hir_ty/src/db.rs#L21
and run the cargo check -p hir_ty --all-targets runnable via rust-analyzer, to get the problems populated.
Then, click a few different ones and notice the number of problems displayed.
Here's how it works for me:

gif

I believe this is caused by this code
https://github.com/rust-analyzer/rust-analyzer/blob/6f3a3bdde4e526d880b9d8d9c613d2cef50a5f3b/crates/rust-analyzer/src/main_loop.rs#L650-L659


Improve DI token management

All custom providers should use an InjectionToken instead of a class/string reference.
Internal providers should be more distinguishable within a modules Provider/Injectable map.

Solved using providedIn: ctx & InquirableFactory.


added node-version 20, 21, 22 for windows/macos/linux binaries

I need this package to be available for Node 20 on the project I'm currently working on.
I raised this issue https://github.com/microsoft/ApplicationInsights-node.js-native-metrics/issues/60, so I thought I could update the workflows to help everyone.
@microsoft-github-policy-service agree

@microsoft-github-policy-service agree

@microsoft-github-policy-service agree

Duplicated of #62

Duplicated of #62
I created this so that we can move ahead with the changes.
The person who raised the pr #62  hasn't accepted the CLA agreement. It's been more than two weeks.
And more than a month since I raised this issue https://github.com/microsoft/ApplicationInsights-node.js-native-metrics/issues/60


Consider add your repo to go-awesome

Hello, this is just a tip. Consider add your repo in: https://github.com/avelino/awesome-go I did this years ago in my open-source project maroto and after this the repo started to receive more visits.
Also, do you have any social network? as Linkedin? I'm about to release an article (in brazilian portuguese) explain how to use your project (go-arch-lint). I would like to mention you.

hi, thanks for your interest.

Consider add your repo in: https://github.com/avelino/awesome-go
yes, a little later (after v4 release) I will think about it.

about specifying me, it's not necessary, but you can mention my github profile if you like.


Please show the canonical way to switch between test and production

Thank you for pyfakefs.

I want to start out from the beginning using pyfakefs the right way.  Please
show us how to:

* Use pyfakefs during tests
* Not use pyfakefs in production

The *_test.py tests are of course very informative, but they are always in test
mode.  They do not have a production mode that uses the real file system.

That issue of Testing on the Toilet that introduced pyfakefs would be great.
Even sample source code somewhere on the net would be sufficient.

I would be using the latest version applicable to Python 2.7.

Stackoverflow issue
http://stackoverflow.com/questions/16468443/how-to-replace-file-access-reference
s-for-a-module-under-test asks this same question.

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 1 Oct 2013 at 10:57

Upon moving this project to GitHub project jmcgeheeiv/pyfakefs, I merged the https://code.google.com/r/jmcgeheeiv-pyfakefs/ files, and edited the usage tutorial into the wiki.


Replace boolean parameters with extra string methods

The following methods have a boolean flag parameter:
std::vector<std::string> split(std::string str, char delim = ',', bool skip_empty = true);
std::string join(std::vector<std::string> strs, char delim, bool skip_empty = true);
std::string join(std::vector<std::string> strs, bool skip_empty = true);

The problem with bool parameters, is they are not very self documenting at the point of call. In particular, for a call such as the following, there's no way for someone to infer what the boolean does without reading additional documentation, or finding the method definition:
auto result = split(string, ',', false);

Instead of using boolean flag parameters, two versions of the methods can be provided. For instance, there might be a split, and splitStripEmpty, or join, and joinSkipEmpty. This would provide much better documentation at the point of call about what is intended.
As a side benefit, it also allows lifting the boolean checks out of the inner loops of the above methods, and effectively make them static decisions at the point of call. That should result in more optimized code.

One other option to consider is a using a scoped enum:
enum class StringOptions
{
    SkipEmpty
    PreserveEmpty
    //...
};

//Declarations
std::vector<std::string> split(std::string str, char delim = ',', const StringOptions& opts);
std::string join(std::vector<std::string> strs, char delim, const StringOptions& opts);
std::string join(std::vector<std::string> strs, const StringOptions& opts);

//Calls
split(string, ',', StringOptions::PreserveEmpty);
join(strings, ',', StringOptions::SkipEmpty);
join(strings, StringOptions::PreserveEmpty);

It self-documents at both the call site and declaration, avoids duplicating code with another function definition and the implementation doesn't have to change that much.

Yes, a scoped enum is more self documenting. However, if the enum values are going to be hardcoded constants, you're pushing a compile time decision into a runtime check.
Consider the difference between the following:
Original:
while (std::getline(ss, curString, delim)) {
	if (skip_empty && curString.empty()) { continue; }
	result.push_back(curString);
}

Branch lifted out of inner loop:
if (skip_empty) {
	while (std::getline(ss, curString, delim)) {
		if (curString.empty()) { continue; }
		result.push_back(curString);
	}
} else {
	while (std::getline(ss, curString, delim)) {
		result.push_back(curString);
	}
}

Branch lifted out of inner function:
if (skip_empty) {
  splitSkipEmpty(string);
} else {
  split(string);
}

In the last case, if the skip_empty value is likely to be a hardcoded constant, then it doesn't need to be there, nor does the whole if/else block.
For methods like this, that value is almost always going to be a hardcoded constant.

This is like how in the file access API, the seek method was designed to take a direction parameter, so you could seek from the beginning of the file, the current position in the file, or the end of the file. This was almost certainly a mistaken design. The decision as to how seeking should be done was very nearly always a compile time decision.

Hmm...now that I see it, that's actually a nice solution. Skipping empty entries is dependent on the data and for a mature dataset that is unlikely to change so can be a hard-coded design.


Automated cherry pick of #3766: region: host list filter by cdrom_boot

Cherry pick of #3766 on release/2.13.
#3766: region: host list filter by cdrom_boot

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/2.13@22d6ddb). Click here to learn what that means.
The diff coverage is 0%.

@@              Coverage Diff               @@
##             release/2.13   #3768   +/-   ##
==============================================
  Coverage                ?   6.94%
==============================================
  Files                   ?     499
  Lines                   ?   84202
  Branches                ?       0
==============================================
  Hits                    ?    5850
  Misses                  ?   77856
  Partials                ?     496

Flag
Coverage Δ

#aFlag
6.94% <0%> (?)

Impacted Files
Coverage Δ

pkg/compute/models/hosts.go
0.34% <0%> (ø)

pkg/compute/models/specs.go
0% <0%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 22d6ddb...c1887bb. Read the comment docs.

/lgtm

/approve


typo: Double word "Storage"

@nschonni : Thanks for your contribution! The author, @su-jie, has been notified to review your proposed change.

Merging typo fix


Rename db->index in tests and readme

This is every occurrence of "db" except for those in protobuf files - I'm not sure if those can/should be changed here?

Coverage remained the same at 100.0% when pulling e3fee549a94b31f11d358159cdf8086f2fcb1331 on alanbernstein:db-index-rename into 0f97474f5aade9b5fcf45b16be514f54434b94c4 on pilosa:master.

@yuce @alanbernstein we should update the public.proto definition file to be consistent with the server (change "DB" to "Index" in ImportRequest) and regenerate the public.pb.go file.

@travisturner If it's OK I will defer updating the proto file since Go client doesn't support importing yet (and the proto file may change until we implement that)


usb: device: class: rndis: correct packet reception

Allows receive packets that are bigger than CONFIG_RNDIS_BULK_EP_MPS.
Considering:

MaxPacketsPerTransfer is 1
MaxTransferSize is 1558
PacketAlignmentFactor is 0 (20=1)

The rndis_bulk_out shall be able to receive transfers up to 1558 bytes (inclusive).
Fixes #54574.
Tested on a custom board with STM32H730VB embedded USB FS PHY.
This PR is a crude fix and has to be tested on other targets as RNDIS somehow worked for them before.

Added validation that incoming data doesn't exceed RX buffer size. Data and "in" packet are discarded in such case.