Add workflow for testing contrib repo

Fixes #199

@djaglowski - can you please review this PR?

@prasadkatti Would you be willing to update this PR according to Tigran's suggestion on the contrib PR?

if you really need to run just a subset then manually execute the commands that are in the make target in this PR

Yes, I will try it out and reach out if I need help.

@prasadkatti Thank you for the updates! The script looks great, and appears to be finding the correct modules, but unfortunately it's crashing on go mod tidy due to a recent version change. The check reported success, but logged the following:
Run contrib_path=/tmp/opentelemetry-collector-contrib
  contrib_path=/tmp/opentelemetry-collector-contrib
  git clone https://github.com/open-telemetry/opentelemetry-collector-contrib.git $contrib_path
  ./check-contrib.sh
  shell: sh -e {0}
Cloning into '/tmp/opentelemetry-collector-contrib'...
Log collection modules - /tmp/opentelemetry-collector-contrib
/tmp/opentelemetry-collector-contrib/cmd/configschema
/tmp/opentelemetry-collector-contrib/internal/stanza
/tmp/opentelemetry-collector-contrib/receiver/filelogreceiver
/tmp/opentelemetry-collector-contrib/receiver/syslogreceiver
/tmp/opentelemetry-collector-contrib/receiver/tcplogreceiver
/tmp/opentelemetry-collector-contrib/receiver/udplogreceiver
/tmp/opentelemetry-collector-contrib /__w/opentelemetry-log-collection/opentelemetry-log-collection
go mod tidy: go.mod file indicates go 1.17, but maximum supported version is 1.16
go<EMAIL_ADDRESS>missing go.sum entry; to add it:
	go mod download cloud.google.com/go/monitoring
/__w/opentelemetry-log-collection/opentelemetry-log-collection
/tmp/opentelemetry-collector-contrib/cmd/configschema /__w/opentelemetry-log-collection/opentelemetry-log-collection
go mod tidy: go.mod file indicates go 1.17, but maximum supported version is 1.16
...

@djaglowski Yes, I noticed that. Can you give me some pointers on how I could fix that. The container image I used in the github actions workflow points to image: cimg/go:1.16. So what exactly is the issue here?

I'm still seeing failures relating to go version, but the check passes. I believe we need the script to return a non-zero exit code when it fails.
As for the go version issues, it looks like the upgrade to 1.17 happened after you created your branch. Can you please rebase?

@djaglowski - rebased on upstream and pushed the changes. Can you please kick off the workflow?

@prasadkatti Thanks for iterating on this. Looks like it's almost there. I'm happy to see that the failure registers now.
I think it's ok to exclude specifically exclude the root module.

Looks good, thanks @prasadkatti! This is a really nice improvement for this repo.
PASS
ok  	github.com/open-telemetry/opentelemetry-collector-contrib/internal/stanza	0.239s
~/work/opentelemetry-log-collection/opentelemetry-log-collection
/tmp/opentelemetry-collector-contrib/receiver/filelogreceiver ~/work/opentelemetry-log-collection/opentelemetry-log-collection
go: downloading github.com/observiq/nanojack v0.0.0-20201106172433-343928847ebc
go: downloading github.com/bmatcuk/doublestar/v3 v3.0.0
go: downloading go.opencensus.io v0.23.0
go: downloading github.com/gorilla/mux v1.8.0
go: downloading github.com/cenkalti/backoff/v4 v4.1.1
go: downloading go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc v0.22.0
go: downloading github.com/rs/cors v1.8.0
go: downloading go.opentelemetry.io/contrib v0.22.0
go: downloading go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.22.0
go: downloading github.com/shirou/gopsutil v3.21.8+incompatible
go: downloading github.com/felixge/httpsnoop v1.0.2
go: downloading go.opentelemetry.io/otel/metric v0.22.0
go: downloading go.opentelemetry.io/otel/internal/metric v0.22.0
go: downloading github.com/StackExchange/wmi v1.2.1
go: downloading github.com/go-ole/go-ole v1.2.5
PASS
ok  	github.com/open-telemetry/opentelemetry-collector-contrib/receiver/filelogreceiver	0.928s
~/work/opentelemetry-log-collection/opentelemetry-log-collection
/tmp/opentelemetry-collector-contrib/receiver/syslogreceiver ~/work/opentelemetry-log-collection/opentelemetry-log-collection
go: downloading github.com/jpillora/backoff v1.0.0
go: downloading github.com/observiq/go-syslog/v3 v3.0.2
go: downloading github.com/pelletier/go-toml v1.7.0
go: downloading golang.org/x/tools v0.1.2
PASS
ok  	github.com/open-telemetry/opentelemetry-collector-contrib/receiver/syslogreceiver	0.213s
~/work/opentelemetry-log-collection/opentelemetry-log-collection
/tmp/opentelemetry-collector-contrib/receiver/tcplogreceiver ~/work/opentelemetry-log-collection/opentelemetry-log-collection
PASS
ok  	github.com/open-telemetry/opentelemetry-collector-contrib/receiver/tcplogreceiver	0.115s
~/work/opentelemetry-log-collection/opentelemetry-log-collection
/tmp/opentelemetry-collector-contrib/receiver/udplogreceiver ~/work/opentelemetry-log-collection/opentelemetry-log-collection
PASS
ok  	github.com/open-telemetry/opentelemetry-collector-contrib/receiver/udplogreceiver	0.109s
~/work/opentelemetry-log-collection/opentelemetry-log-collection


Respect HTTP01Timeout, improve logging

What this PR does / why we need it:

A context was created with WithTimeout of HTTP01Timeout, but not used in the HTTP requests in testReachability
testReachability completely absorbed HTTP client errors which makes it very hard in some situations to debug issues where the challenge does not succeed (in 0.5.0 it only logs a "... self check failed for domain ..."

/ok-to-test

Thanks for this patch 😄 this should hopefully make things a lot clearer for users when their self-checks are failing.
/lgtm
/approve

/release-note-none

/test e2e v1.12

Not sure where this flake is coming from... let's see if it resolves itself here, and if not then I'll disable the v1.12 e2e until we can debug further.

/skip

/skip

Not 100% sure why this is failing right now, removing lgtm label for the time being to stop the spam!
/lgtm cancel

Retesting since #989 has merged
/retest

/retest

/skip
/lgtm


ORC-791: Upgrade guava test dependency to 30.1.1-jre

What changes were proposed in this pull request?
This PR aims to upgrade the guava test dependency to version 30.1.1-jre.
Why are the changes needed?
This will use the latest version of guava during testing.
How was this patch tested?
Pass the CIs.

Hi, @williamhyun . I'll backport this to branch-1.6 for Apache ORC 1.6.8.


Make ItemLabelGenerator customizable

Currently the ChipCombobox uses a hard coded ItemLabelGenerator which uses Object::toString to render the text of the chips.
This way the used object in the combobox has to override the toString()-method to change the displayed text.
It would be nice to have a setter for the ItemLabelGenerator like every other Vaadin-component with items to change the rendered text of an Chip:
ChipCombobox<TestDTO> cbo = new ChipCombobox<>();
cbo.setItemLabelGenerator(TestDTO::getDisplayProperty);

Also consider implementing delegate setters for the internal Combobox to make it easier to set its ItemLabelGenerator and possibly its Renderer too.
ChipCombobox<TestDTO> cbo = new ChipCombobox<>();
cbo.setComboboxItemLabelGenerator(TestDTO::getDisplayProperty);
cbo.setComboboxRenderer(new TextRenderer<>(TestDTO::getDisplayProperty));
cbo.setChipItemLabelGenerator(TestDTO::getDisplayProperty);

Todo: Add missing setter/with-Method and getter

I'll be working on this issue


Shadows Classes

I added some shadows classes which are missing.

Shouldn't you add them on the raw scss files instead of on the compiled css?

Please do not edit our generated dist files

These are random classes and values, thanks but we'll pass. I have something else in mind.


Fix spelling mistake with codespell

codespell -w -i2 -L ans,nd,allo pkg
add a pre-commmit config for it
add a task for pac ci
Signed-off-by: Chmouel Boudjnah<EMAIL_ADDRESS>Changes

Submitter Checklist

[ ] 📝 A good commit message is important for other reviewers to understand the context of your change. Please refer to How to Write a Git Commit Message for more details how to write beautiful commit messages. We rather have the commit message in the PR body and the commit message instead of an external website.
[ ] ♽ Run make test before submitting a PR (ie: with pre-commit, no need to waste CPU cycle on CI. (or even better install pre-commit and do pre-commit install in the root of this repo).
[ ] ✨ We heavily rely on linters to get our code clean and consistent, please ensure that you have run make lint before submitting a PR. The markdownlint error can get usually fixed by running make fix-markdownlint (make sure it's installed first)
[ ] 📖 If you are adding a user facing feature or make a change of the behavior, please verify that you have documented it
[ ] 🧪 100% coverage is not a target but most of the time we would rather have a unit test if you make a code change.
[ ] 🎁 If that's something that is possible to do please ensure to check if we can add a e2e test.
[ ] 🔎 If there is a flakiness in the CI tests then don't necessary ignore it, better get the flakyness fixed before merging or if that's not possible there is a good reason to bypass it. (token rate limitation may be a good reason to skip).
The go tests was not running in the commit introducing this change and
it was failing without us knowing.

/retest


consolidate the final chains property and fix revealed off-by-one in genLeaderSchedule

Currently on master, LeaderSchedule and Praos use prop_all_common_prefix (unless the schedule is too crowded, then it discards/gives up) while BFT and PBFT use allEqual.
This PR consolidates all of that logic into a common property. This involves eliminating the CrowdedRun logic in favor of a more direct and general computation. Beyond the inherent simplification, this is in anticipation of #773: letting nodes join late generalizes the notion of too crowded in such a way that will affect all the protocols.
Also, #827 should have included the fix off-by-one bug in genLeaderSchedule commit, but the related test wasn't failing until this PR. This is because the new property based on determineForkLength is more demanding than what was being used before.

bors r+


Update to Chembl 31

Description
Use the current chembl version (31).
The only change in behavior is in the uniprot query in human_kinases.ipynb. The old query did not work anymore. I have adjusted the query to the interface as described on uniprot.org.
TODO

[ ] EGFR-bioactivites-in-chembl.ipynb is not updated, because it downloads the kinodata release of the respective Chembl version.

Status

[ ] Ready to go

@jchodera and @mbackenkoehler should we draft a new release then (https://github.com/openkinome/kinodata/releases/)?

Issue #18 should be resolved before this is merged.

In the meantime, we are at ChEMBL 33. I ran the update and adjusted the kinase filtering step because kinase.com is down.

@mbackenkoehler I just tried the human_kinases.ipynb notebook and the uniprot query seems to be failing for me. I don't know if this is a blocker for this PR but just wanted to bring this to your attention. The traceback of it is in https://gist.github.com/ijpulidos/10cca1331577d4e24d168408431f6da2 and this was the output of running the following code (part of human_kinases.ipynb)
from urllib.parse import quote
url = ("https://www.uniprot.org/uniprot/?query="
       + quote(r'family:"protein kinase superfamily" AND reviewed:yes AND organism:"Homo sapiens (Human) [9606]"') +
       "&format=tab&force=true&columns=id,entry%20name,reviewed,protein%20names,genes&sort=name")
uniprot = pd.read_csv(url, sep="\t").rename(columns={"Entry": "UniprotID"})
reviewed_uniprot = SOURCES["our_uniprot"] = uniprot[uniprot.Status=="reviewed"].drop("Status", axis=1)

Yes, that issue needs to be solved before doing the release.

@mbackenkoehler oh, you might be right!! I just realized this is from your fork and I was confused about both master branches. I'm going to test this as soon as possible and get back to you. Sorry about this!

@mbackenkoehler you were right, again apologies for this confusion. Things are running fine with your fork.

No worries! Thanks for helping out!


Add scrollwheel input to spin slider

Adds the ability to adjust the editor's spin slider with the mouse wheel, when hovering over the spin slider's grabber. By requiring the mouse to be hovered over the grabber, using the mouse wheel for scrolling up and down the inspector is still possible.
#17371

Wouldn't this be problematic when the user scrolls in the inspector and inadvertently puts their mouse on the grabber icons?

I guess you could also require the left mouse button to use the scroll wheel.

Thanks!


Typo in Compliance Assert feature

The compliance_assert feature is listed as compliance_assert in amqprs/Cargo.toml, but in the code where the features are toggled with #[cfg(feature = "compilance_assert")]. See the transposition error in compliance vs compilance. Is this intentional? Also, the module is listed as compilance_assert.rs. This may be correct, but it seems like this would cause a disconnect?

oh... they are exactly typo, not intentional :)


Added size and capacity to CacheStats.

Resolve #47.

I don't think it makes sense to add the capacity to the cache statistics since it is constant and can just be accessed statically. The cache statistics should represent data that may change over the life of the cache. Otherwise looks great! Thanks for this!

Fixed. Thanks.


2.0: API - DO - Unable to add a node to cluster

Summary of Issue:
We are unable to add a node to Digital Ocean.
Steps to Reproduce:

Create a cluster in DO
Add a node of any size

This was previously working.
Expected Results:
The node is added without issue.
Actual Results:
The node is not created and the attached error is thrown in the SG logs.
INFO[0066] createMachineDigitalOcean                     ERRO[0067] update kube state caused storage: get: entity not found  ERRO[0067] update kube state caused storage: get: entity not found  ERRO[0067] add node to cluster af394673 caused an error dropletService has returned an error in Run job: POST https://api.digitalocean.com/v2/droplets: 400 (request "90197717-a69c-4b2e-96bf-d2b264f8a9dd") Error validating resource tag: "tag-name \"\" contains invalid characters"
Dev Info: (fill out and add links to log files)

go version: 1.10
SG latest commit hash or release tag: ba6ac33b7e5339f5355ef13a360190e6b0b2c4c5
Number of Masters and Nodes: Any
cloud provider: DIgital Ocean

@eldridgeh Looks like tag name was invalid, what was cluster name?

This is working


kubevirt datavolume with insecure registry

What happened:
DataVolume create failed with
root@ubuntu:/data/kubevirt# kubectl describe datavolume fedora-cloud-base -n vm-images
Name:         fedora-cloud-base
Namespace:    vm-images
Labels:       <none>
Annotations:  <none>
API Version:  cdi.kubevirt.io/v1beta1
Kind:         DataVolume
Metadata:
  Creation Timestamp:  2022-05-23T02:41:12Z
  Generation:          9
  Managed Fields:
    API Version:  cdi.kubevirt.io/v1alpha1
    Fields Type:  FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          .:
          f:kubectl.kubernetes.io/last-applied-configuration:
      f:spec:
        .:
        f:pvc:
          .:
          f:accessModes:
          f:resources:
            .:
            f:requests:
              .:
              f:storage:
        f:source:
          .:
          f:registry:
            .:
            f:url:
    Manager:      kubectl-client-side-apply
    Operation:    Update
    Time:         2022-05-23T02:41:12Z
    API Version:  cdi.kubevirt.io/v1beta1
    Fields Type:  FieldsV1
    fieldsV1:
      f:status:
        .:
        f:claimName:
        f:conditions:
        f:phase:
        f:progress:
        f:restartCount:
    Manager:         cdi-controller
    Operation:       Update
    Time:            2022-05-23T02:41:19Z
  Resource Version:  1927470
  UID:               28a95c27-ec1e-48c7-9b03-b2a44ad3ae8f
Spec:
  Pvc:
    Access Modes:
      ReadWriteOnce
    Resources:
      Requests:
        Storage:  5Gi
  Source:
    Registry:
      URL:  docker://<IP_ADDRESS>/library/fedora36:latest
Status:
  Claim Name:  fedora-cloud-base
  Conditions:
    Last Heartbeat Time:   2022-05-23T02:41:13Z
    Last Transition Time:  2022-05-23T02:41:13Z
    Message:               PVC fedora-cloud-base Bound
    Reason:                Bound
    Status:                True
    Type:                  Bound
    Last Heartbeat Time:   2022-05-23T02:41:18Z
    Last Transition Time:  2022-05-23T02:41:12Z
    Status:                False
    Type:                  Ready
    Last Heartbeat Time:   2022-05-23T02:41:18Z
    Last Transition Time:  2022-05-23T02:41:18Z
    Message:               Unable to process data: Unable to transfer source data to scratch space: Failed to read registry image: Could not create image reference: pinging container registry <IP_ADDRESS>: Get "https://<IP_ADDRESS>/v2/": dial tcp <IP_ADDRESS>:443: connect: connection refused
    Reason:                Error
    Status:                False
    Type:                  Running
  Phase:                   ImportInProgress
  Progress:                N/A
  Restart Count:           1
Events:
  Type     Reason            Age                From                   Message
  ----     ------            ----               ----                   -------
  Normal   Claim Pending     15s                datavolume-controller  target PVC fedora-cloud-base Pending and Claim Pending
  Normal   Pending           14s (x2 over 15s)  datavolume-controller  PVC fedora-cloud-base Pending
  Normal   ImportScheduled   14s                datavolume-controller  Import into fedora-cloud-base scheduled
  Normal   Bound             14s                datavolume-controller  PVC fedora-cloud-base Bound
  Normal   ImportInProgress  10s                datavolume-controller  Import into fedora-cloud-base in progress
  Warning  Error             9s                 datavolume-controller  Unable to process data: Unable to transfer source data to scratch space: Failed to read registry image: Could not create image reference: pinging container registry <IP_ADDRESS>: Get "https://<IP_ADDRESS>/v2/": dial tcp <IP_ADDRESS>:443: connect: connection refused

What you expected to happen:
create datavolume success from registry
How to reproduce it (as minimally and precisely as possible):
Steps to reproduce the behavior.
cat << END > fedora-cloud-base-datavolume.yaml
apiVersion: cdi.kubevirt.io/v1alpha1
kind: DataVolume
metadata:
  name: fedora-cloud-base
  namespace: vm-images
spec:
  source:
    registry:
      url: "docker://<IP_ADDRESS>/library/fedora36:latest"
  pvc:
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 5Gi
END
kubectl create -f fedora-cloud-base-datavolume.yaml

Additional context:
Add any other context about the problem here.
Environment:

KubeVirt version (use virtctl version): N/A
0.53.0
Kubernetes version (use kubectl version): N/A
1.24.0
VM or VMI specifications: N/A
Cloud provider or hardware configuration: N/A
OS (e.g. from /etc/os-release): N/A
Kernel (e.g. uname -a): N/A
Install tools: N/A
Others: N/A

@willzhang you should open the issue in the CDI repository rather than in kubevirt. Have you tried to access the registry from one of the nodes in the cluster, like for example pulling the image using crictl? Additionally, can you ping the registry from inside one of the other containers?


Cannot find module 'OTLPTraceExporter' imported from /app/server/index.mjs

Description
We are importing @opentelemetry/exporter-trace-otlp-http in our setup code. Everything was working fine till v0.52.1, but the following error is coming after updating to v0.53.0. The error is coming when we are starting the node server.
Error message
Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/app/node_modules/.pnpm/@opentelemetry+exporter-trace-otlp-http@0.53.0_@opentelemetry+api@1.9.0/node_modules/@opentelemetry/exporter-trace-otlp-http/build/src/platform/node/OTLPTraceExporter' imported from /app/server/index.mjs
    at finalizeResolution (node:internal/modules/esm/resolve:265:11)
    at moduleResolve (node:internal/modules/esm/resolve:933:10)
    at defaultResolve (node:internal/modules/esm/resolve:1157:11)
    at ModuleLoader.defaultResolve (node:internal/modules/esm/loader:390:12)
    at ModuleLoader.resolve (node:internal/modules/esm/loader:359:25)
    at ModuleLoader.getModuleJob (node:internal/modules/esm/loader:234:38)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:87:39)
    at link (node:internal/modules/esm/module_job:86:36) {
  code: 'ERR_MODULE_NOT_FOUND',
  url: 'file:///app/node_modules/.pnpm/@opentelemetry+exporter-trace-otlp-http@0.53.0_@opentelemetry+api@1.9.0/node_modules/@opentelemetry/exporter-trace-otlp-http/build/src/platform/node/OTLPTraceExporter'
}

Additional Details

This is a Nuxt app monorepo, setup with Nx and pnpm.
On version 0.52.1, after the build,  @opentelemetry/exporter-trace-otlp-http was present in the package.json of the build dir .output. And was also imported in the index.mjs file. After the update, it is not present in the above places, and instead, its code is inline in the server chunk index.mjs.
This error is coming for version 0.55.0 as well.

OpenTelemetry Setup Code
// src/server/plugins/tracing.ts
import { Resource } from '@opentelemetry/resources';
import { SEMRESATTRS_SERVICE_NAME } from '@opentelemetry/semantic-conventions';
import { BatchSpanProcessor } from '@opentelemetry/sdk-trace-base';
import { NodeTracerProvider } from '@opentelemetry/sdk-trace-node';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { registerInstrumentations } from '@opentelemetry/instrumentation';
import { HttpInstrumentation } from '@opentelemetry/instrumentation-http';
import type {
  HttpRequestCustomAttributeFunction,
  IgnoreIncomingRequestFunction
} from '@opentelemetry/instrumentation-http';
import type { Span } from '@opentelemetry/api';
import type { ClientRequest, IncomingMessage } from 'http';

export default defineNitroPlugin(() => {
    const {
      traceExporterEndpoint,
      apiKey,
      appName,
      appEnv,
      otelExporterThresholds
    } = getOpentelemetryConfig();

    // Configure the OTLP exporter
    const exporterConfig: ExporterConfig = {
      url: traceExporterEndpoint,
      headers: {
        'api-key': apiKey
      },
      concurrencyLimit: otelExporterThresholds.concurrencyLimit
    };

    // Initialize OTEL trace exporter
    const exporter = new OTLPTraceExporter(exporterConfig);

    // Create a NodeTracerProvider instance
    const provider = new NodeTracerProvider({
      resource: new Resource({
        [SEMRESATTRS_SERVICE_NAME]: `${appName}-${appEnv}-server`
      })
    });

    provider.addSpanProcessor(
      new BatchSpanProcessor(exporter, {
        maxExportBatchSize: otelExporterThresholds.maxExportBatchSize,
        scheduledDelayMillis: otelExporterThresholds.scheduledDelayMillis,
        exportTimeoutMillis: otelExporterThresholds.exportTimeoutMillis,
        maxQueueSize: otelExporterThresholds.maxQueueSize
      })
    );

    // Register the provider with OpenTelemetry
    provider.register();

package.json
{
  "name": "...",
  "version": "0.0.0",
  "license": "MIT",
  "scripts": {
    "preinstall": "npx only-allow pnpm",
    "docs": "typedoc"
  },
  "private": true,
  "dependencies": {
    "@opentelemetry/api": "1.9.0",
    "@opentelemetry/exporter-trace-otlp-http": "0.53.0",
    "@opentelemetry/instrumentation": "0.53.0",
    "@opentelemetry/instrumentation-http": "0.53.0",
    "@opentelemetry/resources": "1.28.0",
    "@opentelemetry/sdk-trace-base": "1.28.0",
    "@opentelemetry/sdk-trace-node": "1.28.0",
    "@opentelemetry/sdk-trace-web": "1.28.0",
    "@opentelemetry/semantic-conventions": "1.28.0"
  }
}

Relevant log output
No response
Operating System and Version
No response
Runtime and Version

Operating System: Linux
Node Version:     v20.12.0
Nuxt Version:     3.13.2
Package Manager<EMAIL_ADDRESS>Nx: v20.0.5

Hi, thanks for reaching out - I've looked into this and found some weird behavior around comments when building with Nuxt. Going from 0.52.1 to 0.53.0, we added this comment here:
https://github.com/open-telemetry/opentelemetry-js/blob/fc94e4669a94e688204a919165a020323fc1d5c2/experimental/packages/exporter-trace-otlp-http/src/index.ts#L18
It's absolutely astonishing, but removing that comment above, here and here for some reason makes it work. I narrowed it down to the string export * in a comment causing trouble when used with Nuxt. It breaks using both // and /* comments
I'm fairly certain that this is a bug or limitation with the build tooling that's in use here. Does anyone have an insight/link to what I may be looking at?

I made a reproducer so that we can verify that changing the comment actually fixes things:
https://github.com/open-telemetry/opentelemetry-js/issues/5218

Self assigning since I have a fix at #5227

Hi @pichlermarc, thank you for this fix.
Do you know when is the next release date? As we are stuck due to this.

please see https://github.com/open-telemetry/opentelemetry-js/pull/5232 for tracking release progress 🙂


Tasks.json option to overwrite build shell doen't work

VSCode Version: 1.39.2
OS Version: Windows 10

Steps to Reproduce:

Set a build shell which is different than default

    "windows": {
        "options": {
            "shell": {
                "executable": "C:/Windows/System32/WindowsPowershell/v1.0/powershell.exe"
            }
        }
    },

Run build and see that it is using original shell, not one defined in .vscode\tasks.json

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

Stumbled on it when was trying find a way around with https://github.com/microsoft/vscode/issues/83023

I can't reproduce this. I used this task:
		{
			"label": "Test powershell",
			"command": "Write-Host \"hello there\"",
			"type": "shell",
			"problemMatcher": [],
			"windows": {
				"options": {
					"shell": {
						"executable": "c:\\windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe"
					}
				}
			}
		},

Can you share your whole exact task?

@alexr00 Place you are inserted is against VSCode schema. windows is not part of tasks elements. I believe you had no code competition when you added windows.
Here is my tasks file. I had to remove options of a task to make it work on Mac.
{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "windows": {
        "options": {
            "shell": {
                "executable": "C:/Windows/System32/WindowsPowershell/v1.0/powershell.exe"
            }
        }
    },
    "tasks": [
        {
            "type": "typescript",
            "tsconfig": "tsconfig.json",
            "problemMatcher": [
                "$tsc"
            ],
            "group": "build",
            "presentation": {
                "echo": true,
                "reveal": "always",
                "focus": false,
                "panel": "dedicated",
                "showReuseMessage": true,
                "clear": false
            },
            "options": {
                "shell": {
                    "executable": "C:/Windows/System32/WindowsPowershell/v1.0/powershell.exe"
                }
            }
        }
    ]
}

My example task is a proper task and you should see windows as a suggestion in a task :)
Since you have options in your task they override the windows specific options above. We always keep the configuration from the individual task over the "global" configurations.

@v-andrew it

Looks like "windows" isn't an option when you use a task type other than "shell" or "process". Since you're using a typescript task you are not seeing the windows property.

There are OS specific properties in VS code.
They are available on a level higher than task.
So it is not a feature request.
@alexr00  I do not ask to add a new feature.
Just reporting that feature which is available - brocken.
Please check for yourself that all thouse keys are avalable right now.:
{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "windows": {
        "options": {
            "shell": {
                "executable": "C:/Windows/System32/WindowsPowershell/v1.0/powershell.exe"
            }
        }
    },
    "tasks": [
        {

Keys for "OSX" , "Linux" are available along side with "windows"
All keys added to example above are available in VSCode.

https://github.com/microsoft/vscode/issues/83021#issuecomment-544836509 ans https://github.com/microsoft/vscode/issues/83021#issuecomment-544988734 *
When copied code to my tasks.json VSCode marked it as incorrect:

When I'm trying to build it doesn't affect my default shell set to bash and ignores option suggested by person, who incorrectly closed previous issue:

OS option is unavailable in Windows and MacOS at the level suggested. Here is screenshot on Mac:

As you can see, there is no OS option at that level. The same behavior as on Windows.

@alexr00 Option to add OS specific option is available in VSCode in the different level of tasks.json:

So this is not feature-request, but issue


[Photoprism] No https

I use home assistant with duckdns + let's encrypt addon .
I set port forwarding according to the port included in the configuration panel of the Photoprism addon (version 220302-impish).
I do not have https and firefox tells me that the website (photosprims gui) is unsecure.
How can I have secure connection?
Thank you

Hi, https with ssl definition is now implemented in the latest version

Please let me know if everything went fine

Great job @alexbelgium
Https is working now as expected once ssl toogle is activated in the config panel!
Thank you so much!

Thanks for the feedback!


Realm createOrUpdateInDefaultRealmWithValue breaks after adding an NSData object

See the following repository for an example
https://github.com/MikeSilvis/realm-create-or-update/blob/master/Realm Create Or Update/ViewController.m
That results in the following output:
2015-10-23 14:56:10.690 Realm Create Or Update[69017:3580508] initial creation and find of ticket objectID: 123 withSeat: 2
2015-10-23 14:56:10.696 Realm Create Or Update[69017:3580508] Verify seat is still persisted even though we didnt add it again objectID: 123 seat:
2015-10-23 14:56:11.324 Realm Create Or Update[69017:3580858] after we added a PDF to the ticket: 123 seat:  length: 2716227
2015-10-23 14:56:11.359 Realm Create Or Update[69017:3580858] Now that we created and saved a new obj 123 seat:  and pdf 0

I think this is the intended behavior. If you'd like to update object partially, you should not include properties not to be updated to the object.
You passed ticket object that has zero length pdf data property by default, so existing object will be overwritten.
If you'd like to partial update, you can do following:
[realmTwo transactionWithBlock:^{
    [MSTicket createOrUpdateInDefaultRealmWithValue:@{@"objectID": objectId, @"seat": @"3"}];
}];

@kishikawakatsumi why would a defaultPropertyValues override an existing property value? The default value should only be called if there isn't something in realm to be used otherwise because Realm doesn't understand nil.

I can't really use your example without knowing if the object exists or not already in the database. Basically createOrUpdateInDefaultRealmWithValue is pointless because no matter what I need to do a db lookup and then conditionalize around what to do if it is or not

Are you talking about line 77-86, right?
defaultPropertyValues doesn't overwrite existing value. You create new object at line 77 https://github.com/MikeSilvis/realm-create-or-update/blob/master/Realm Create Or Update/ViewController.m#L77, that is filled by default values. Then you passed the object to createOrUpdateInDefaultRealmWithValue: https://github.com/MikeSilvis/realm-create-or-update/blob/master/Realm Create Or Update/ViewController.m#L81, so existing object will be overwrite default values.
Do I understand your queastion correctly?

@kishikawakatsumi yes. defaultValues in my opinion should not be called basically until we go to save we see the object doesn't exists and then we add them just to ensure things aren't nil. Because if I just do this:
MSTicket *ticket = [MSTicket new];
NSLog(@"seat is: %@", ticket.seat);

It is going to return nil, not empty string.
Basically what you are implying is I need to always write something like this:
MSTicket *dbTicket = [MSTicket objectWithPrimaryKey:@"123"];
if (dbTicket) {
 // update my values
}
else {
  // Create the new object.
}

Essentially I am just trying to get around the unnecessary conditional and IMO realm should just see that the property is nil, and not try and set it on an existing object.

defaultValues in my opinion should not be called basically until we go to save

No, the objects will be filled with default values immediately after the object was created.
https://github.com/realm/realm-cocoa/blob/master/Realm/RLMObjectBase.mm#L45-L48
Your code is one of the solution, since Realm does not support partial update yet https://github.com/realm/realm-cocoa/issues/2644.
Or passed by dictionary as I mentioned.

@kishikawakatsumi okay. I guess basically i'm asking for just a partial update function.


Dio throws wrong error type

Package
dio
Version
5.0.1
Output of flutter doctor -v
❯ flutter doctor -v
[✓] Flutter (Channel stable, 3.7.5, on macOS 13.0.1 22A400 darwin-x64, locale en-AU)
    • Flutter version 3.7.5 on channel stable at /Users/timnew/Workspace/flutter_sdks/production
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision c07f788888 (6 days ago), 2023-02-22 17:52:33 -0600
    • Engine revision 0f359063c4
    • Dart version 2.19.2
    • DevTools version 2.20.1

[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.0)
    • Android SDK at /Users/timnew/Library/Android/sdk
    • Platform android-33, build-tools 33.0.0
    • Java binary at: /Applications/Android Studio.app/Contents/jre/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.13+0-b1751.21-8125866)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 14.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 14B47b
    • CocoaPods version 1.12.0

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2021.3)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.13+0-b1751.21-8125866)

[✓] VS Code (version 1.75.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.58.0

[✓] Connected device (3 available)
    • iPhone 14 Pro (mobile) • 8B1B6C6A-211B-431E-9BD3-7EEBF6D33029 • ios            •
      com.apple.CoreSimulator.SimRuntime.iOS-16-1 (simulator)
    • macOS (desktop)        • macos                                • darwin-x64     • macOS 13.0.1 22A400 darwin-x64
    • Chrome (web)           • chrome                               • web-javascript • Google Chrome 105.0.5195.125

[✓] HTTP Host Availability
    • All required HTTP hosts are available

• No issues found!

Dart Version
2.19.2
Steps to Reproduce

Calling API, which is expected to return JSON when succeeded
API returns 403 due to token issue, which content-type as text/html instead of application/json (Due to WAF or so)
Expected to have DioError[badResponse] but got DioError[unknown]

Expected Result
Dio throws DioError[badResponse]
Actual Result
Dio throws DioErro[unkown]
flutter: Error: DioError [unknown]: null
Error: FormatException: Unexpected character (at character 1)
error code: 1020
^
flutter: Stack:
#0      _ChunkedJsonParser.fail (dart:convert-patch/convert_patch.dart:1383:5)
#1      _ChunkedJsonParser.parseNumber (dart:convert-patch/convert_patch.dart:1250:9)
#2      _ChunkedJsonParser.parse (dart:convert-patch/convert_patch.dart:915:22)
#3      _parseJson (dart:convert-patch/convert_patch.dart:35:10)
#4      JsonDecoder.convert (dart:convert/json.dart:610:36)
#5      JsonCodec.decode (dart:convert/json.dart:216:41)
#6      jsonDecode (dart:convert/json.dart:155:10)
#7      _decodeJson
#8      SyncTransformer.transformResponse
sync_transformer.dart:123
<asynchronous suspension>
#9      DioMixin._dispatchRequest
dio_mixin.dart:567
<asynchronous suspension>

The issue is caused because Dio trys to parse body as json regardless its content-type in response header.
The issue doesn't occur in Dio 4.x, only starts in 5.0

Issue caused by https://github.com/cfug/dio/blob/42b7eb838a3e6e73fdb93478b2992e0f36eba39b/dio/lib/src/dio_mixin.dart#L558-L571
Not sure how receiveDataWhenStatusError is set to true, even though I'm sure didn't manually doing that.
forceConvert enforced the dio override the server content-type when parsing the body, which doesn't make anysense

I am getting the same error when I assigned content-type: application/json; charset=utf-8

As I don't need the body for error response, so I'm kind of workaround the issue by manually set receiveDataWhenStatusError to false in baseOptions, which is set to true by default.
But I guess this would still be an issue for those who need error response.

Not sure what 4.x behaviour was, but I tried to add an kill switch in options to avoid this forceConvert behaviour, which I don't run into error here any more.
But I run into an assertion error later that dio assert the response.data is the type T. As if the incoming content-type is text/html, so I got string, which fails the assertion.
Due to the complexity, I found the easiest solution for this is to set receiveDataWhenStatusError to false.

set dio options:
dio.options.contentType = Headers.formUrlEncodedContentType;
working for me

cc @ipcjs. Can you help to identify if this is a regression that has been invented since #1490?

I haven't added tests yet but would like to know if #1711 solves the issue.


improve health check

Netflix ribbon is removed in latest spring cloud, old health check will not work
issue: in cluster mode, we are relying on health check to remove invalid node
requirements:
we need to have a way to let access knows all registered proxys

discarded, we removed eureka and no need to do health check


Solar power preparation

This change will be regarding tracking of apartment energy usage between two cycles: day and night.
In theory, when there is enough data available, it could make it easy to calculate your energy usage and create optimal off-grid/inline PV system + battery capacity needed.

First part is done #3fbba6988880b873820270a1e76287cb90ab29cb

Would love to see a video explaining this in more detail.

Would love to see a video explaining this in more detail.

Hopefully it will be worth doing it, but that was the general idea.

So far, so good - it's working nicely...
This is output from .csv file that's created at midnight
Home Assistant notifications (Log started: 2020-08-11T23:50:50.855669+00:00)
--------------------------------------------------------------------------------
2020-08-11,0.15,1.11,7.63,None,None,unknown,6.81
2020-08-12,6.06,3.12,9.18,None,None,unknown,7.82
2020-08-13,7.75,3.18,10.93,None,None,unknown,9.52
2020-08-14,8.32,4.10,12.42,None,None,unknown,10.66
2020-08-15,9.56,3.01,12.57,None,None,unknown,10.98

And there is screenshot from GUI

One is tracking peak/offpeak electricity, and other one is tracking electricity usage during da and night.

And nice visual representation of energy usage vs day/night:

Have to stress once again this all was inspired and based on following project:
https://community.home-assistant.io/t/daily-energy-monitoring/143436

This has been working very nicely for last 30+ days.
Still have to add expand on this, but closing for now.

This is my Lovelace card (HACS mini graph card).
It uses binary sensor created above and current consumption from Shelly EM.
color_thresholds:
  - color: '#039BE5'
    value: 0
  - color: '#0da035'
    value: 600
  - color: '#e0b400'
    value: 1200
  - color: '#e45e65'
    value: 2400
color_thresholds_transition: hard
entities:
  - sensor.shelly_em_current_consumption
  - color: 'rgba(0,0,255,1)'
    entity: binary_sensor.dark_outside
    show_line: false
    y_axis: secondary
group: false
hour24: true
hours_to_show: 24
line_width: 4
points_per_hour: 4
show:
  extrema: true
  fill: fade
  icon: true
  labels: false
  name: true
  state: true
state_map:
  - label: Day
    value: 'off'
  - label: Night
    value: 'on'
style: |
  ha-card {
    border: solid 2px var(--primary-color);
  }
type: 'custom:mini-graph-card'

Thanks for this! In the code above, what displays the min and max values?

In the code above, what displays the min and max values?

Mini Graph Card has one parameter for show:
extrema | false | true / false | Display max/min information.
So this is built in the card itself.

Brilliant, thank you!


v2: Firmware available?

It would be good to have a binary of the firmware that the device uses. The board has two unpopulated JTAG headers along with a Silex Technology SX-ULPGN chip and a RIGADO BMD-300 chip.
The SX-ULPGN supports a serial debug UART on pins 38 and 39. The BMD-300 allows SWD read back of the firmware (the version in the Petnet Feeder 2.0 is the AD version that is not locked).

I connected a serial console to the SX-ULPGN and it outputs the following. It resets every 30 seconds or so:
reset cause:RESET_1
_WAKEMGR_Register  item:0x43a558
cmnos_allocram_init: start=0x44eaf0 size=725064
NUM_DEV=2 FWMODE=5 FWSUBMODE=0 FWBR_BUF 1
Mac address is : [removed]
wlan power patch
_WAKEMGR_Register  item:0x43e194
RegDB opened
AMSDU enabled
WNM INIT
_WAKEMGR_Register  item:0x467230
_WAKEMGR_Register  item:0x469f38
alloc rem: 593068
host_dset_init
_host_dset_do_init
ram_dset_init
otp_dset_init
rom_dset_init
mem_dset_init
DataSet asynchronous initialization done (0)

I bought a little SWD device from Amazon and connected it to the BMD-300 SWD connector (J101) on the main board. I used OpenOCD to dump the firmware contents to inspect with Ghidra.

Here's a list of the API calls I could see:
/api/v1/kronos/software/releases/transactions/
/api/v1/core/events
/api/v1/kronos/software/releases/transactions
/api/v1/kronos/software/releases/transactions/%s/received
/api/v1/kronos/software/releases/transactions/%s/succeeded
/api/v1/kronos/software/releases/transactions/%s/failed
/api/v1/kronos/devices
/api/v1/kronos/gateways

These look like possible JSON API fields:
_|deviceHid
s|local_md5
s|msg_type
sensor
f|voltage
i|usb
i|chg
i|rssi
i|btn
i|mem
s|pnid
s|fw_ver
s|wifi
s|log
feed_result
s|s_id
s|s_p
s|s_act
s|s_auto
s|s_r
s|s_t
i|stime
i|etime
f|e_g
f|a_g
f|h_s
f|h_e
i|src
b|fail
s|err
s|rid
b|online
s|remote_md5

Here are my notes from looking at the handlers for messages via MQTT:
Outgoing message types (6 total):
Topic = "krs.tel.gts.<clientId>"

0 - boot
1 - sensor
{"_|deviceHid":"ad06c3b579d59b2045fe01c37d18ca7252336935","s|msg_type":"sensor","f|voltage":4086,"i|usb":1,"i|chg":0,"i|ir":1,"i|rssi":99,"i|btn":1,"i|mem":5648}
2 - feed_result
{"_|deviceHid":"ad06c3b579d59b2045fe01c37d18ca7252336935","s|msg_type":"feed_result","i|stime":1601883341,"i|etime":1601883343,"f|e_g":27,"f|a_g":0,"f|h_s":-133,"f|h_e":-133,"i|src":5,"b|fail":true,"s|err":"Unknown Error","s|rid":""}
3 - hb (heartbeat)
{"_|deviceHid":"ad06c3b579d59b2045fe01c37d18ca7252336935","s|msg_type":"hb","b|online":1}
4 - trace (debug trace)
{"_|deviceHid":"ad06c3b579d59b2045fe01c37d18ca7252336935","s|msg_type":"trace","i|tl":32,"s|ts":"Start - D�, Portion: 0 tbsp(309448g), Turns: 41, Bowl: 0g, Hopp"}
{"_|deviceHid":"ad06c3b579d59b2045fe01c37d18ca7252336935","s|msg_type":"trace","i|tl":32,"s|ts":"Results - Actual: 536928072 tbsp(0g), End: 309476, Bowl: 44g Ho"}
5 - hash
{"_|deviceHid":"ad06c3b579d59b2045fe01c37d18ca7252336935","s|local_md5":"9f12737513eebebdfa70ca72fa562c45","s|msg_type":"hash","s|remote_md5":"26a98b0dc2ae400c65711957f5a14d5a"}

Incoming message type:

reboot
feed
portion (tablespoons?)
Possible other incoming messages (not sure what the actual commands are):
button_enable_remote
schedule ??
active
automatic
feeding_id
reminder

Test data from firmware?	[{"active":true,"automatic":true,"feeding_id":"40006b28dbdfd7b2_zbxM2a_11:46AM","name":"FEED2","portion":0.0625,"reminder":false,"time":%ld}]

budget ??
tbsp_per_feeding
recipe
g_per_tbsp
budget_tbsp

Test data in firmware:
{"budget_cups":0.75,"cups_per_feeding":0.25,"kcals_per_cup":519,"kcals_per_day":389.75,"kg_per_cup":0.10421836228287841,"managed":false,"num_feedings":3,"recipe":"E0000060"}

utc ?? (maybe:utc_offset)
utc_offset

ohhhhhh, so I was seeing the first three API interactions and it was then appearing dead. That's because it flipped to MQTT?
great work. lemme get you on Slack, though it's quiet.. I've been waiting for someone to make forward progress.

I started back up the MQTT server and got it to try to dispense. My hopper is empty so it spun for probably 20 seconds fruitlessly. I'm not sure what the portion measurements mean yet.
You have to look at what topic it subscribes to. My PetNet is subscribing using the client ID 40285608b03f085d1b4e31ec5f60b3b912f64f2d and deviceHid of ad06c3b579d59b2045fe01c37d18ca7252336935 in the example below.
hbmqtt_pub --url mqtt://localhost:1883/ -t 'krs/cmd/stg/40285608b03f085d1b4e31ec5f60b3b912f64f2d' -m '{"hid":"feed1","name":"SendCommand","encrypted":false,"parameters":{"deviceHid":"ad06c3b579d59b2045fe01c37d18ca7252336935","command":"feed","payload":"{\"portion\":2}"}}'

The feeder will send an HTTP-via-MQTT response to topic krs.api.gts.40285608b03f085d1b4e31ec5f60b3b912f64f2d of something like:
{"requestId":"GS-2020-10-06T00:18:47.000Z","eventName":"GatewayToServer_ApiRequest","encrypted":false,"parameters":{"uri":"/api/v1/core/events/feed1/received","method":"PUT","apiKey":"efa2396b6f0bae3cc5fe5ef34829d60d91b96a625e55afabcea0e674f1a7ac43","apiRequestSignature":"dc6ba210d41c72ae2997e1c7ddcdb36316e55356061fa09c30db558c1279a330","apiRequestSignatureVersion":"1","timestamp":"2020-10-06T00:18:46.000Z"},"signature":"8198cf30c1a98972d238680fe92798d3124dfa66653f58a6f2d607935330a564","sign
atureVersion":"1"}')}

You must respond to the requestId (in this example GS-2020-10-06T00:18:47.000Z) with a HTTP 200 OK equivalent status before it will proceed:
hbmqtt_pub --url mqtt://localhost:1883/ -t 'krs/api/stg/40285608b03f085d1b4e31ec5f60b3b912f64f2d' -m '{"requestId":"GS-2020-10-06T00:18:47.000Z","eventName":"GatewayToServer_ApiRequest","encrypted":false,"parameters":{"status":"OK"}}'

@kruton , I'm trying to replicate your findings on a first generation feeder. If I followed you correctly, point mqtt-a01.arrowconnect.io to a machine on your local network (I use pihole and love it!). Start a mosquitto broker on that machine and the feeder should start publishing messages to that broker?
If so, I've spent some time on it and it seems gen 1 is not mqtt-aware :-(

Everything about the gen1 is different, Fred. Seriously, no hardware or software or APIs are common to them (afaict).

@fbretmounet do you have any pictures of the electronics on the V1 feeder? It seemed like all the smarts may have been in the bowl.

@kruton , yes it is under the bowl. I took the attached pictures when I opened it a few weeks ago. Let me know if you want more pictures!

Looks like this might be a design based on electricimp imp003. Are there any pictures of the overall board? I'd be more interested to see if there are pads to connect debug cables as mentioned in their documentation.

Here are picture of the top of the board and a picture of the back only showing test pads. I did not find obvious jtag or serial pads. I did not find standard debug documentation from electricimp. :-(
https://developer.electricimp.com/hardware/imp/imp003pinmux suggests quite a few different combinations for serial... I guess I could try every one of them...

When the gen1 discussion came up in the past, it sounded like the Imp was shipped in "production mode", locking down a lot of the debugging and such.

 The alternative is to rebuild my own board :-(
Get Outlook for Androidhttps://aka.ms/ghei36

From: Ted Timmons<EMAIL_ADDRESS>Sent: Wednesday, October 7, 2020 11:38:37 AM
To: tedder/petnet-api-hacking<EMAIL_ADDRESS>Cc: Fred Bret-Mounet<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [tedder/petnet-api-hacking] Firmware available? (#12)
When the gen1 discussion came up in the past, it sounded like the Imp was shipped in "production mode", locking down a lot of the debugging and such.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/tedder/petnet-api-hacking/issues/12#issuecomment-705121497, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AINWVLD7ZWMUVYZN5NGUCILSJSYS3ANCNFSM4OOF5PEQ.

You could order a V2 on Amazon for $65 :)

Such a bummer.  Honestly hate the idea of just chucking the whole
thing into the trash, but I don't know what else I'd do with it. I already
bought a PetKit feeder, which seems to do the job just as well.
On Wed, Oct 7, 2020 at 1:58 PM Kenny Root<EMAIL_ADDRESS>wrote:

You could order a V2 on Amazon for $65 :)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tedder/petnet-api-hacking/issues/12#issuecomment-705131689,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABXHM2G7IGS4TQCSLXGRSYDSJS26VANCNFSM4OOF5PEQ
.

Couldn't you reverse engineer the petnet android app to point to a url
you've constructed with mqt? I assume there might be a variable in there
somewhere that points to these endpoints.
On Wed, Oct 7, 2020, 3:02 PM Brian Beaird<EMAIL_ADDRESS>wrote:

Such a bummer.  Honestly hate the idea of just chucking the whole
thing into the trash, but I don't know what else I'd do with it. I already
bought a PetKit feeder, which seems to do the job just as well.
On Wed, Oct 7, 2020 at 1:58 PM Kenny Root<EMAIL_ADDRESS>wrote:

You could order a V2 on Amazon for $65 :)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<
https://github.com/tedder/petnet-api-hacking/issues/12#issuecomment-705131689
,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/ABXHM2G7IGS4TQCSLXGRSYDSJS26VANCNFSM4OOF5PEQ
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tedder/petnet-api-hacking/issues/12#issuecomment-705133494,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AI7EVLF3OHQW2EX4NMKYT7DSJS3LLANCNFSM4OOF5PEQ
.

I don't know what the V1 looks like on the network. I would suggest trying to do packet captures of what it's sending across the network (or trying to send now that PetNet's domains are defunct).

I already bought a PetKit feeder, which seems to do the job just as well.
…
Gen1 guy here, new to the thread. I JUST bought a PetSafe unit from eBay last night to replace our feeder. I see this comment and look it up, looks like exactly what I want - Bluetooth to program if their servers disappear being a big draw. Oh well.

Hey gen1 folks, this is hard to thread, please go into #15 to work on efforts there. @fbretmounet can you repost your images and text there? I'm going to delete the messages from this thread.

There's a 8Mbit flash chip on my 2.0 device board that I can read through a programmer. It seems contains some firmware and it disassembles as a ARM binary.
However, I didn't put much effort in the firmware but I just replaced the main board with a resperberry pi to just drive the motor from time to time. I lost all the weight sensors and motion sensors, but it's the quickest way that I can get my feeder back to work.

Closing this out since we have pretty much everything working with the V2 feeders.

Hi @kruton :wave:
Any chance you could post the firmware image?


Naming

dudes?!
http://www.whale-world.com/what-is-a-group-of-whales-called/

The project's already called swarm. It was a missed opportunity, but what can you do ¯\(ツ)/¯

:stuck_out_tongue:


Converting "post" activities to microformats2 loses content

Moved over from https://github.com/snarfed/ownyourresponses/issues/1
Calling microformats2.object_to_json on a "verb": "post" activity drops "content" and "in-reply-to". (See previous issue for example)
I think we've missed this because activitystreams.py calls microformats2.object_to_json directly on activity["object"] (which works for notes but is lossy for likes and shares)
It also occurs to me that https://github.com/snarfed/granary/commit/2d8510d57d24a5ce15437e3ef47aafd4869fefbc was the wrong solution -- instead of passing the activity["object"] and activity["context"], we should always pass activity to object_to_json, if we can.

right, that makes sense. we need that inner object for pretty much everything except original posts, so to tighten up this representation and make it more correct, we'd want to rename object_to_json to activity_to_json and always pass the activity. there may be a few catches to porting all callers, since iirc maybe one or two don't have the activity handy, but we can figure that out.

hah. i just noticed that ownyourresponses uses an old pre-granary activitystreams-unofficial module from february. sooooo yeah, we probably shouldn't pay too much attention to that part of it. :P a first step might be to update ownyourresponses to use granary in a virtualenv. :P

I did do that, but honestly what I want ownyourresponses to do is
different enough from what you want it to do, that it's probably not
worth trying to merge my changes in.
I'm really impressed with how little code ownyourresponses has in it, by
the way.
On 10/7/2015 1:29 PM, Ryan Barrett wrote:

hah. i just noticed that ownyourresponses uses an old pre-granary
activitystreams-unofficial module from february. sooooo yeah, we
probably shouldn't pay too much attention to that part of it. :P a
first step might be to update ownyourresponses to use granary in a
virtualenv. :P
—
Reply to this email directly or view it on GitHub
https://github.com/snarfed/granary/issues/44#issuecomment-146318651.

fixed in #47


PingAsync() causing failures in Azure Function Runtime 3.0

It would seem that the current release of nClam (4.0.1) is unusable within v3.0 of the Azure Function Runtime due to an issue with the PingAsync() method. After going back and forth with Microsoft, we discovered that the method works just fine at v2.0 but not the new v3.0 runtime.
The issue only surfaces when an v3.0 Azure Function attempts to call the PingAsync() method against an IP that falls within RFC1918 which produces the error An attempt was made to access a socket in a way forbidden by its access permissions. [::ffff:<IP_ADDRESS>]:3310.
The IP getting used is malformed and after digging into that, its because newer versions of dotnet core default to use ipv6 and you have to explicitly use ipv4 methods due to the Azure Function Runtime being dual stack (basically it has to be flagged to use ipv4 and this does happen if you use the proper method built into dotnet core, Ping.SendAsync)
I found the following method to handle either ipv6 or ipv4.  https://docs.microsoft.com/en-us/dotnet/api/system.net.ipaddress.maptoipv4?view=netcore-3.1

@bguidinger I assume this is the same issue you are referring to here, correct?
https://github.com/tekmaven/nClam/issues/37#issuecomment-619008010

I believe this is actually a .net Core 3.0 and above issue and can be an issue in any .net application, not just Functions.
nClam uses TcpClient without specifying the address space. On .net core 3.0 and above, that means it defaults to IPv6. This causes an issue when you are working on an Azure VNET which does not support IPv6.
The fix (as specified in issue #37 ) is to use var clam = new TcpClient(AddressFamily.InterNetwork); (which mandates IPv4) or even use something like
var clam = new TcpClient(AddressFamily.InterNetworkV6);
clam.Client.DualMode = true;

See

https://github.com/MicrosoftDocs/azure-docs/issues/45991
http://www.lybecker.com/blog/2018/08/23/supporting-ipv4-and-ipv6-dual-mode-network-with-one-socket/

I do not know if this library is alive any more and whether it is worth doing a PR for it? @tekmaven ?

@martinkearn I get the impression from the lack of updates/responses that your PR will be ignored as I believe this project is dead from an ongoing update perspective which is unfortunate.
Nevertheless, thanks for the clarification on the fix required. May have to fork and maintain my own copy moving forward unfortunately.

This fix is merged.  Will be releasing a new major nuget version shortly.


broken pipe

Describe the bug
I am encountering a persistent "broken pipe" error when running Terragrunt with the Google Cloud provider. The error appears after the provider authenticates successfully but before any resources are created or modified. This issue occurs consistently, regardless of network or machine.
Steps To Reproduce

Set up a GCP project and create a service account with the necessary permissions.
Configure the following Terragrunt and Terraform files:

# Root terragrunt.hcl
generate "provider" {
  path = "providers.tf"
  if_exists = "overwrite"
  contents = <<EOF
provider "google" {
  project = var.project_id
  region  = var.region
}

provider "google-beta" {
  project = var.project_id
  region  = var.region
}

terraform {
  required_version = "v1.9.2"
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "5.38.0"
    }
    google-beta = {
      source  = "hashicorp/google-beta"
      version = "5.38.0"
    }
  }
}
EOF
}

# Child terragrunt.hcl (in gcf directory)
include {
  path = find_in_parent_folders()
}

inputs = {
  project_name          = local.env_vars.project_name
  project_suffix        = local.env_vars.project_suffix
  project_id            = local.env_vars.project_id
  region                = local.env_vars.region
  service_account_email = local.env_vars.service_account_email
  bucket_name           = local.env_vars.bucket_name
  capacity_gb           = 1024
  zone                  = local.env_vars.zone
}

Run terragrunt init successfully.
Run terragrunt apply -auto-approve.

The error message appears as follows:
21:28:43.777 ERROR  terraform invocation failed in /mnt/c/Users/KarelMacek/PycharmProjects/temus-dialogforge-infrastructure/terraform/gcp/resources/demo/gcf error=[/mnt/c/Users/KarelMacek/PycharmProjects/temus-dialogforge-infrastructure/terraform/gcp/resources/demo/gcf] signal: broken pipe
21:28:43.778 ERROR  1 error occurred:
        * [/mnt/c/Users/KarelMacek/PycharmProjects/temus-dialogforge-infrastructure/terraform/gcp/resources/demo/gcf] signal: broken pipe

Expected behavior
I expected the terragrunt apply process to complete without errors, proceeding with the resource creation and modification after successful authentication with the Google Cloud provider.
Nice to haves

[x] Terminal output

Versions

Terragrunt version: 0.67.4
OpenTofu/Terraform version: v1.9.2
Environment details: Ubuntu 22.04.3 LTS

Additional context
I've tried the following steps to troubleshoot the issue:

Increased verbosity with TF_LOG=DEBUG
Verified GCP credentials and permissions
Attempted from different machines and networks, but the issue persists.

Any suggestions or insights would be greatly appreciated. Thank you!

Hello,
tried to run with --terragrunt-non-interactive, it is generating the same error?

This issue was reaised before and fixed iirc; have you tried the latest version of TG?

Hey @KarelMacek ,
To avoid having this issue go stale, please do the following:

Provide a fully reproducible example if the issue you are facing (no undefined local values, etc).
This will help us reproduce the scenario you are encountering, allowing us to ensure that it's still and issue, and that we are correctly addressing the problem.

Retest on v0.68.1. That is the latest version of Terragrunt, and per @dalgibbard 's comment, a similar issue was fixed after 0.67.4.


#38 - Add support for additional targets using plugin configuration

PR to imlplement the requested behaviour

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Luca Tagliani seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


'context' undefined in rescue_from in 2.1.0

After updating from 2.0 to 2.1, some of our error handling tests broke. We have various error handlers that would catch errors globally and log some info and we used the context for that. For example:
rescue_from :all do |e|
  log_context = {
    useragent: context.env['HTTP_USER_AGENT'],
    method: context.env['REQUEST_METHOD'],
    url: context.env['PATH_INFO'],
    querystring: context.env['QUERY_STRING'],
    ip: context.env['HTTP_X_REAL_IP'],
    accept: context.env['HTTP_ACCEPT'],
    content_type: context.env['CONTENT_TYPE'],
    params: context.params,
  }
  logger.log(e, log_context)
  error!(e, e.status)
end

But now with 2.1, we're getting:
NameError: undefined local variable or method `context' for #<#<Class:0x0000000323776e08>:0x0000000324f45700>
    ruby/lib/grape/error_handling.rb:103:in `block in <module:ErrorHandling>'

I'll try to dig in tomorrow to see if I can figure out which commit caused it, but figured I'd give folks a heads up

I believe it's because of https://github.com/ruby-grape/grape/pull/2363/ the Grape::Middleware::Helpers module is no longer eager loaded. Adding helpers Grape::Middleware::Helpers fixes the issue.

@krismichalski your close but the helper is included and loaded in Grape::Middleware::Base and Grape::Middleware::Auth::Base
Nonetheless, I think I know what the issue, since #2377, rescue_from are endpoint.instance_exec instead of instance_exec. Since the endpoint, doesn't have the helper included, this is why doing helpers Grape::Middleware::Helpers make it works.

oh, I didn't notice it was loaded there, sorry for the wrong accusation ^^" I'm glad the root cause was discovered 👍

@krismichalski Can you please take a look at https://github.com/ruby-grape/grape/blob/master/UPGRADING.md and make sure it accurately describes this situation for the next person?

@mscrivo could you checkout my branch and see if it works ?

@ericproulx your branch seems to work great, our tests are passing

Thanks for fixing this @ericproulx.


Create an interactive Dice Roller app: Android Basics with Compose

URL of codelab
https://developer.android.com/codelabs/basic-android-kotlin-compose-build-a-dice-roller-app?continue=https%3A%2F%2Fdeveloper.android.com%2Fcourses%2Fpathways%2Fandroid-basics-compose-unit-2-pathway-2%23codelab-https%3A%2F%2Fdeveloper.android.com%2Fcodelabs%2Fbasic-android-kotlin-compose-build-a-dice-roller-app#2
A name of an Activity should not contain a whitespace. i.e. The name should be DiceRollerActivity etc, instead of Dice Roller.

@hsseek
Thank you for reaching out to us. The name of Activity could be any, as the whitespace doesn't affect anything. But there should be no whitespaces in the location path as it can cause problems with NDK tools.


Versus Dynamic DNS?

Is there a substantial difference between this and dynamic DNS (RFC 2136)? It looks like the code simply allows publishing a node ID to address(es) mapping, both for IPv4 and IPv6. It would be easier for people to run their own discovery server -- and for scaling the public ones -- if it didn't require maintaining custom software with its own API.

+1 Great work thus far guys!

DNSSEC and even DANE are not really what we want:
http://sockpuppet.org/blog/2015/01/15/against-dnssec/
http://sockpuppet.org/stuff/dnssec-qa.html
https://www.imperialviolet.org/2015/01/17/notdane.html
FYI The first two posts are from Thomas Ptacek, a well known security professional and the third is from Adam Langley, Googles security guru, who also wrote the (probably) most secure anonymous communication tool that exists: Pond.

Whatever reputation Ptacek may have, his post on DNSSec is incompetent.
It's not government-controlled PKI. It's controlled by the applicable TLD, only some of which are government-run. Additionally, certificate pinning provides zero access to private keys. At its worst potential abuse, a government could use it to cause broswers to show incorrect warnings.
It's not cryptographically weak because DNSSec isn't a specific algorithm any more than TLS is a specific encryption algorithm. Conflating the two shows lack of familiarity with the topic.
It's unclear why he thinks it's expensive to adopt or deploy, either, given that Google, Comcast, and other major vendors validate DNSSec data.
It's also not "incomplete," at least in any way that is substantially different from a browser using an OS-shipped set of CAs for TLS. Either you trust the OS or you don't. If you can't trust the OS to validate DNS lookups, then why would you trust it to ship trustable CAs?
The claim that DNSSec in unsafe relies purely on a "security through obscurity" hypothesis. It's quite important to prevent forgery of non-existent records, as it can redirect things like emails through forging higher-priority records than the correct ones. His only criticism against NSEC3 (including its solution to record disclosure) is that it's, apparently, complicated.
Also, DANE isn't at all what we've been talking about here, which is the only thing Langley is mentioning.

DNSSec not government-controlled PKI. It's controlled by the applicable TLD, only some of which are government-controlled, and those are generally ones like ".us". In the FAQ, he acknowledges this but counters that "Google can't opt out of .com," which is a different argument -- and not one particular to DNSSec.

This kind of arguing is handwaving at best and malevolent at worst. If the root authorities of the trust system are sometimes adversaries, you can't simply put the average web user in charge of knowing the precise influence some governments may have on some domains. This kind of "experts will figure out how to do it securely" thinking is why we still don't have usable crypto, decades after the groundwork was laid.
This is so basic that it shouldn't need an example. But still. Take a look at the popularity statistics for TLDs:
http://w3techs.com/technologies/overview/top_level_domain/all
Wow, number three on this list with nearly 5% of all TLDs ever registered is .ru. Hmm wasn't there something a few years ago about this? Yes, in 2012 a government controlled blacklist was introduced with the charming name "Common register of domain names, Internet website page locators, and network addresses that allow identifying Internet websites which contain information that is prohibited for distribution in the Russian Federation."
You can read more about it here:
https://en.wikipedia.org/wiki/Internet_censorship_in_Russia
There have also been several documented attacks on the security of encrypted connections by countries like Turkey.
Regarding that Google can't opt out of .com: Of course this is relevant to DNSSEC. Not only to DNSSEC, but to every trust management system supposed to replace the incredibly broken X509 infrastructure. It means that the domain a website is registered under can not have an influence oo the trustworthiness of the connection. If the entity providing the trust isn't both trustworthy AND separate from the domain registrar, the system is broken.

DANE-based certificate pinning provides no access to private keys. Ptacek wrongly implies that it does in the Bit.ly example.

No, his bit.ly example only talks about DNSSEC. And DNSSEC doesn't solve the problem that state-owned or state-controlled registries have the power to subvert an encrypted connection, because they are the trust anchor.

DANE-based certificate pinning provides no access to private keys. Ptacek wrongly implies that it does in the Bit.ly example. The worst potential abuse is a TLD owner publishing false public keys for domains and signing bad records. This abuse would cause browsers visiting those domains to possibly show certificate warnings or fail DNS lookups. If a TLD wants to take down a site, they would just mess with the nameserver records and be done; DNSSec doesn't offer them more power to compromise sites. What DNSSec does do it take the power to propagate bad DNS records away from everyone but the site owner and TLD.

Right, but if we are already going to replace a horribly broken system, we shouldn't replace it with a system, which is better in some aspects, but still doesn't really solve all the problems.

DNSSec is also not cryptographically weak because DNSSec isn't any specific signing algorithm. The same concerns for signing algorithms apply to both TLS and DNSSec. Conflating DNSSec with its current algorithm options shows lack of familiarity with the system, at best. RSA is hardly broken, anyway.

Yes, yes it is cryptographically weak. You are basically saying all the currently deployed implementations are weak and there is no big effort to improve this ASAP, but it can be improved, if we replace the bad signing algorithms with something stronger in the future.
With this kind of arguments TLS can be cryptographically stronger (not trustworthier) than this part DNSSEC, because some servers use strong ciphers, whereas strong signing algos aren't even part of the current DNSSEC set.

RSA is hardly broken, anyway.

1024 bit RSA can certainly be considered broken, since several state actors are believed to have the power to break them in acceptable time today. Which means that bigger companies or organized criminals will be able to do it in 5 years, while everbody else will be able to break it at home in 10 years.

Ptacek also says in the FAQ that the curves supported by DNSSec may be older but aren't actually broken.

And this is exactly what is generally beeing said before stuff breaks fantastically. Look at RC4. It was even used by many big services, even though it was known to be old and not state of the art, because it prohibited another attack. And then it imploded.
This follows your reasoning pattern to dismiss any criticism of algorithms as long as they are not completely broken just yet. Which simply doesn't reflect how security professionals work: regard everything that is not known to be good as possibly broken and avoid it.

He portrays DNSSec as expensive to adopt or deploy by the trick of moving goalposts. He considers DNSSec "not deployed" until it's validated down to every OS or application, which ignores the power of validation Google, Comcast, and others perform. [...] My computer's security isn't just a product of the browser's validations.

What do you want to say about the power of validation?  And any system that doesn't siginficantly improve in this regard is broken.
The argument that it is difficult to deploy certainly holds some truth. Most registrars don't even offer it, many charge a markup and the fact that you found two which do it for free doesn't mean that it's commonly easily and cheaply deployed. It's like saying that TLS certificates are free, because there are one or two CAs which hand out free certificates.

DNSSec is also not "incomplete," at least in any way that is substantially different from a browser using an OS-shipped set of certificate authorities (CAs). If you can't trust the OS to validate DNS lookups, then you can't trust it to ship good CAs. Obviously, cases like Lenovo's recent flap show that it's not always a good idea to trust the OS, but that's not a DNSSec-specific issue.

DNSSEC is supposed to be used as a protocol on the lowest levels, but still doesn't provide the assurances needed from a system that is supposed to replace what we have now.
That's not as user-replaceable as the OS.
From Ptaceks post:

Even if DNSSEC was deployed universally and every zone on the Internet was signed, a coffee-shop attacker would still be able to use DNS to man-in-the-middle browsers.

From your post:

Nothing stops applications from performing their own DNS lookups anyway; it's actually very common.

And now endusers are supposed to check if the programs they care about do this? Please...

Ptacek claim that DNSSec is unsafe relies on a "security through obscurity" approach of hiding host information. It's actually more important to prevent forgery of non-existent records because forged, high priority MX records can redirect things like emails to malicious targets. Of course, DNSSec has actually solved the disclosure issue with NSEC3, which he mentions. His only criticism against NSEC3 is that it's, apparently, complicated.

No it isn't. It's that the default is insecure and that the supposed workaround is a joke where some fake entries are made to make cracking harder.
And not publicly devulging the addresses under which testing, staging and production servers can be reached is not security trough obscurity. Just like changing the SSH port to something else isn't. At the very least it significantly reduces the noise in the log files, by filtering out standard port scans by script kiddies. At best less competent attackers won't even start a targeted attack, because they don't know where to begin. Oh and btw: the more complicated a system is, the higher the likelyhood of vulnerabilities.
In his words:

In the past couple years (reminder: DNSSEC has been “ready to deploy” for almost 15 years), the DNSSEC standards project has solved this problem, if we accept as a “solution” “NSEC3 and “minimum covering NSEC records” with online signers managing DNS zones as a sort of bizarro Unix password file in which fake records are added at random to foil password crackers Confused? Don’t worry, there’s an NSEC5 coming too. . This mode of deployment is, of course, not the default.

For everyone who accepts the default, every hostname in their DNS zones are public information. This works for the kind of person who works on standardizing DNS extensions, because their hostnames are things like “dec-multia-in-my-basement.greybeard.com”. It does not work so well for Bank of America.

And as everybody with experience in security knows: if the defaults aren't good, there will be many spectacular incidences of the system failing.

Finally (and most importantly), DANE isn't actually what we've been talking about here, which is the only thing Langley mentions. Langley is also more charitable than I am with Ptacek's piece; he merely says, "We don't fully agree on everything." I think Langley's piece is quite good, though his annoyance with 1024-bit RSA is not well founded as long as DNSSec serves as additional verification/forgery difficulty, not the single source of truth.

And again: that something isn't entirely broken and utterly useless just yet is certainly no reason to use it.

What I was proposing was regular host records (A and AAAA) for the sake of discovering peers by fingerprint or other name. Obviously, you want the data to be trustworthy and the service to scalable. DNSSec may not be the best answer for that in SyncThing's case, but arguments for and against should be based in good data, not rants.

Apart from that we disagree on the rant part, I don't think requiring DNSSEC from everybody who wants to run a discovery server is going to do the state of decentralization any good.
The more difficult it is to setup (and DNSSEC is a BIG dependency), the less people will be able to run their own.
To quote @AudriusButkevicius:

Why do we need to verify the authenticity of the relay, if the messages the relay is relaying are themselves verifiable and not temperable with?

This kind of arguing is handwaving at best and malevolent at worst. If the root authorities of the trust system are sometimes adversaries, you can't simply put the average web user in charge of knowing the precise influence some governments may have on some domains. This kind of "experts will figure out how to do it securely" thinking is why we still don't have usable crypto, decades after the groundwork was laid.

With CAs, every authority is a potential adversary. Some authorities are government-controlled, making all certificates vulnerable to them. With DNSSec, you have one potential adversary: the authority over the TLD's keys. That may be a government, but at least it's only one.

Wow, number three on this list with nearly 5% of all TLDs ever registered is .ru.

It shouldn't be a surprise that registering a domain under .ru puts the domain at the discretion of the Russian government. Whether that discretion only includes nameservers or also includes DNSSec, they can choose to take down sites from their TLD that they don't like.

Not only to DNSSEC, but to every trust management system supposed to replace the incredibly broken X509 infrastructure.

DNSSec does not intend to replace x.509 in any part. Even with DANE certificate pinning, it's just an additional (and optional) source of trust that makes a CA compromise less of a disaster.

No, his bit.ly example only talks about DNSSEC.

He said, "Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY’s TLS keys." That's completely false. Every browser validates the x.509 chain to a CA, regardless of using DANE. At most, a browser will also check the fingerprint against a DANE record as a second trust anchor. If someone forges malicious DANE records, that will not cause browsers to trust that fingerprint (or the corresponding certificate). It would cause browsers implementing DANE to question or disallow use of the proper certificate, which would be denial of service at most.
It would have been impossible to "control Bit.ly's TLS keys" using DNSSec.

And DNSSEC doesn't solve the problem that state-owned or state-controlled registries have the power to subvert an encrypted connection, because they are the trust anchor.

As I said before, it's an additional trust anchor, not a replacement one. Compromising a single trust anchor (of two, the second being the CA) does not allow subverting an encrypted connection. Denial-of-service isn't subversion of encryption.

1024 bit RSA can certainly be considered broken, since several state actors are believed to have the power to break them in acceptable time today. Which means that bigger companies or organized criminals will be able to do it in 5 years, while everbody else will be able to break it at home in 10 years.

"Broken" is a technical term in cryptography; it means that a finding the key for a given piece of encrypted data has become considerably faster than brute-force, even in limited situations (weak keys or known/supplied text). RSA is not broken in this sense. The ability to brute-force 1024-bit keys simply means longer keys are necessary. DNSSec supports 2048-bit RSA and longer, and people should use those if they want to use RSA. This is no more a problem for DNSSec than TLS or other systems where algorithms are selectable.

And this is exactly what is generally beeing said before stuff breaks fantastically. Look at RC4. It was even used by many big services, even though it was known to be old and not state of the art, because it prohibited another attack. And then it imploded.

Comparing current NIST elliptic curve algorithms to RC4 is unfair. RC4 has been known broken for over a decade, and was suspected to be for far longer. There are no known issues with the EC algorithms in DNSSec, even suspected.

This follows your reasoning pattern to dismiss any criticism of algorithms as long as they are not completely broken just yet.

No, my reasoning that DNSSec offers secure algorithms is based on prevailing opinions in the cryptography community -- and understanding that anything DNSSec provides is additional security versus no signing at all. That means "broken" DNSSec results in falling back to nothing at all (or, at worst, denial of service).

What do you want to say about the power of validation?  And any system that doesn't siginficantly improve in this regard is broken.

DNSSec keys have to be loaded into a registrar, so at least there's not the ability to achieve "domain validation" through DNS, email, or putting a file onto an HTTP server. All of those "domain validation" methods are also subject to compromise without DNSSec or existing TLS, the latter of which creates a chicken/egg situation for obtaining the first domain-validated certificate. So, yes, I'd say it is better than the way we do domain validation right now -- and also allows domain validation to be more secure.

The argument that it is difficult to deploy certainly holds some truth. Most registrars don't even offer it, many charge a markup and the fact that you found two which do it for free doesn't mean that it's commonly easily and cheaply deployed. It's like saying that TLS certificates are free, because there are one or two CAs which hand out free certificates.

The CAs that hand out free certificates (like CAcert) aren't trusted widely by browsers, making them unusable for most purposes. In contrast, registrars that provide free DNSSec key publishing are equal to any other registrar that does so. Moreover, some of the largest registrars, like GoDaddy and Gandi, provide free DNSSec. It's possible to deploy DNSSec completely for free in a trusted way, so there's really no comparison.
In any case, DNSSec doesn't compete with x.509, so DNSSec isn't a solution to problems with certificate costs.

DNSSEC is supposed to be used as a protocol on the lowest levels, but still doesn't provide the assurances needed from a system that is supposed to replace what we have now.

There's no "supposed to be" other than "as many places as possible." It should be like bouncers checking for fake IDs: when they find one, they take it and throw it out, preventing further use of the ID under less critical eyes. And, again, it's not supposed to replace anything we have now.

And now endusers are supposed to check if the programs they care about do this? Please...

Just as it's the responsibility of browsers to make end-users aware of whether an HTTPS connection is secure, browsers can do the same for any lookups they may do (or using other trust mechanisms, like DANE). DNSSec doesn't have a better answer for surfacing security data to the user, but I don't think it's any worse.

It's that the default is insecure and that the supposed workaround is a joke where some fake entries are made to make cracking harder.

It makes it harder in the sense that cracking long-key RSA is hard. The "fake" records are, essentially, the established distributed systems concept of using tombstones to indicate deleted records. It's a signed tombstone that establishes the "deletion" of any record that should not exist so that one cannot be forged (and old but originally legitimate records get flushed).

Oh and btw: the more complicated a system is, the higher the likelyhood of vulnerabilities.

You're raising these concerns about vulnerabilities without asking the critical question of "What happens if that breaks? How bad is it?" If NSEC3 breaks, then you could get addresses and pinned public keys, which should not compromise anything directly. NSEC3 is defense-in-depth, just as unlisted hosts on any DNS server should be defense-in-depth.

And as everybody with experience in security knows: if the defaults aren't good, there will be many spectacular incidences of the system failing.

I'm not really clear on what Ptacek means by "not the default." NSEC3 is one among the two methods for publishing the tombstone records. As far as I can tell, it's neither the default nor not the default. Maybe Ptacek thinks it's "not the default" because it's slightly newer than the record-revealing method, but NSEC3 is still mandatory. Any functional default comes from what DNS servers and services choose as their defaults.

And again: that something isn't entirely broken and utterly useless just yet is certainly no reason to use it.

I agree that DNSSec offers older algorithm options (in addition to the newer options) that, if used, are less secure. I agree that applications and operating systems don't validate DNSSec nearly as much that ought to for DNSSec to be maximally effective. But I'm still unclear to me why Ptacek or you think DNSSec is broken in any true sense, especially in its intended role as an addition to a "defense in depth" arsenal.
I think a large degree of the argument is what DNSSec is intended to do. I see it like the US Treasury adding an additional, hard-to-forge security feature to paper currency: not perfect or always checked but a useful addition to forgeries.

Apart from that we disagree on the rant part, I don't think requiring DNSSEC from everybody who wants to run a discovery server is going to do the state of decentralization any good.
The more difficult it is to setup (and DNSSEC is a BIG dependency), the less people will be able to run their own.

That's reasonable.

I think this is no longer relevant?
Yeah DDNS is nice, but it's easier to set up an announce server than a DNS server which supports DNSSEC.


[#67] Add build hook (main)

Addresses #67
Still confirming for all the platforms...

[ ] Ubuntu 18
[ ] Ubuntu 20
[x] Ubuntu 22
[ ] Debian 11
[ ] Debian 12
[ ] CentOS 7
[ ] EL8
[x] EL9

Does it work for each OS?

Tracking progress on testing for all the platforms via checklist in OP. Building irods for all the platforms is gonna take a while, so... hang tight.

Everything worked except for Centos 7:
stderr: CMake Error at /opt/irods-externals/cmake3.21.4-0/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find FLEX: Found unsuitable version "2.5.37", but required is at
  least "2.6.1" (found /usr/bin/flex)
Call Stack (most recent call first):
  /opt/irods-externals/cmake3.21.4-0/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:592 (_FPHSA_FAILURE_MESSAGE)
  /opt/irods-externals/cmake3.21.4-0/share/cmake-3.21/Modules/FindFLEX.cmake:264 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  parser/CMakeLists.txt:1 (find_package)

So, here are the options as I see it:

Go find the appropriate version of flex and install it in the build hook
Introduce flex as an external and/or build it ourselves in the project
Don't support Centos 7 for GenQuery2

Or, a fourth option... determine whether the specified minimum version is indeed the minimum required version.

who's declaring that minimum?

The requirement is declared here:
https://github.com/irods/irods_api_plugin_genquery2/blob/d08182c017e88d86f6d680fde17dc346446ff88f/parser/CMakeLists.txt#L1
And using the version provided by Centos 7 causes the build to fail, so... whatever the minimum is, it's something newer than the one provided by Centos 7 :)

Following suggestion from @SwooshyCueb worked for Centos 7

Excellent! Looking over build hook.

Squashed

looking good.

#'d. I guess I'll merge it too :p


Adding debtor bulk update method.

This is a good base for an update debitor method + update contact info and ean.
You might want to edit this a little bit to be more universal, but it's a good start <3
With regards, Napp.

Hi @Svenn1,
Thank you for your PR :+1:

Hi @Svenn1,
Thank you for your PR :+1:

You are welcome ! :)

I would recommend refining the update method though, it's still a bit rough! .. I would do it myself but Napp is keeping me busy busy busy ^^


[meta] 7.0.0 release

Meta ticket for 7.0.0.

[x] Ensure [MapsApi()] and [DescriptorFor()] attributes are correct.
[ ] Ensure sensible defaults for HTTP connections; with reference to: https://github.com/elastic/support-dev-help/issues/4466#event-2206911493 - https://github.com/elastic/elasticsearch-net/blob/37b614a16f6d984bc584a557f4a0362a7cfda480/src/Elasticsearch.Net/Configuration/ConnectionConfiguration.cs#L29
[x] 7.0.0-alpha2 breaking formatter backwards compatibility - https://github.com/elastic/elasticsearch-net/issues/3771 discussed as breaking across major versions not for beta
[x] 7.0.0-alpha2 - Clean up GET /_cluster/stats - https://github.com/elastic/elasticsearch-net/issues/3765 - @codebrain
[x] 7.0.0-alpha2 - Unable to get raw document JSON without deserializing - https://github.com/elastic/elasticsearch-net/issues/3751 @russcam
[x] 7.0.0-alpha2 -Trouble programmatically creating aggregations - https://github.com/elastic/elasticsearch-net/issues/3750 @russcam
[x] 7.0.0-alpha 1 - Wrong converting datetime fields - https://github.com/elastic/elasticsearch-net/issues/3719
[x] Calling ConnectionSettings.DefaultMappingFor throws ArgumentException when the Type has been previously added - https://github.com/elastic/elasticsearch-net/issues/3706
[x] NEST removes null value from after_key Dictionary when aggregating - https://github.com/elastic/elasticsearch-net/issues/3694 @russcam
[x] Fix Query DSL usage tests https://github.com/elastic/elasticsearch-net/pull/3804
[x] 7.0.0 - Clear up Name and Id parameters #3672 - https://github.com/elastic/elasticsearch-net/issues/3672 - https://github.com/elastic/elasticsearch-net/pull/3810
[ ] - Go through the Elasticsearch 7.0.0 release notes

Placeholder currently, we should use this to scope the parity work as well as the implications of types removal and upgrade breaking changes.

How is this going?

Looking at the default connection limit of 80, this seems to have been updated approx 2 years ago on this PR: https://github.com/elastic/elasticsearch-net/pull/2785
After looking into this I am having trouble finding decent guidance on what a sensible default value to be, the consensus is that it is very much use case dependant.
I think the best route forward here is to leave the default of 80 intact and prompt users to override the default if they are experiencing issues.

7.0.0-beta1 has been released:
https://github.com/elastic/elasticsearch-net/releases/tag/7.0.0-beta1
Available from Nuget.

7.0.0-beta1 has been released:
https://github.com/elastic/elasticsearch-net/releases/tag/7.0.0-beta1
Available from Nuget.

Bunches of methods removed from IElasticClient in the 7.0.0-beta1 Nuget package, was that expected to happen?

@lummar which methods in particular? It's likely that they've just been moved.
The 7.x client is still a beta prerelease so there are potentially still breaking changes going into it, but once it's GA, which we're working hard to make happen ASAP, backwards binary compatibility will be maintained for the 7.x major lineage.

@russcam for instance
client.IndexExists("indexname").Exists ... or client.CreateIndex("indexname") ...
A lot of the official examples out there still reference the above methods

@mtbitcoin we will publish release notes to help with this when 7.x reaches GA. For now, please take a look at the 7.0.0-beta1 release notes.
The rationale for making this change is that the Elasticsearch API is now well over 200 endpoints, and having all of these as methods on the root of the client has become increasingly unwieldy over time, and is only likely to become more so as further APIs are introduced in the future.
Within the Elasticsearch rest specifications, the APIs are namespaced into modules, which many of the official clients already use to logically group a set of APIs that should belong together e.g. APIs that operate on indices are grouped under Indices, The change in the .NET client, whilst I totally understand will require changes when upgrading from a previous version to 7.x, will hopefully result in an easier to navigate collection of APIs going forward.

client.IndexExists("indexname").Exists

Use
client.Indices.Exists("indexname").Exists

client.CreateIndex("indexname")

client.Indices.Create("indexname")

I have just installed 7.0.0-beta1 and I can see that ICatResponse<> become CatResponse, as @Mpdreamz mentioned here: https://github.com/elastic/elasticsearch-net/issues/3663#issuecomment-482067265
How could we write unit tests for a method which uses elasticClient.Cat.IndicesAsync() without interacting with Elasticsearch ?
Thank you!

I have just installed the 7.0.0-beta1 and seen that all ElasticClient responses are concrete classes instead of interfaces.
We cannot mock the ElasticClient methods for unit testing anymore, because the response types have internal Set.
How would we create unit tests for types which use ElasticClient? Any idea?

@Mpdreamz @codebrain do we want to consider the Diagnostics changes (https://github.com/elastic/elasticsearch-net/issues/3564) for 7.0 GA? Implementation may have impliciations the audit implementation

@russcam yeah let's get that one in

7.0 is now GA!
https://github.com/elastic/elasticsearch-net/releases/tag/7.0.0
Closing this ticket and will re-open a new ticket for 7.1 meta tracking.


tags-on-commits-list: Cannot read properties of undefined (reading 'pathname')

Description
TypeError: Cannot read properties of undefined (reading 'pathname')
    at getCommitHash (chrome-extension://hlepfoohegkhhmjieoechaddaejaokhf/assets/refined-github.js:6936:35)
    at init (chrome-extension://hlepfoohegkhhmjieoechaddaejaokhf/assets/refined-github.js:8223:132)
    at chrome-extension://hlepfoohegkhhmjieoechaddaejaokhf/assets/refined-github.js:4065:28
    at chrome-extension://hlepfoohegkhhmjieoechaddaejaokhf/assets/refined-github.js:4061:64
    at Array.map (<anonymous>)
    at chrome-extension://hlepfoohegkhhmjieoechaddaejaokhf/assets/refined-github.js:4061:45
    at runFeature (chrome-extension://hlepfoohegkhhmjieoechaddaejaokhf/assets/refined-github.js:4062:10)
    at setupPageLoad (chrome-extension://hlepfoohegkhhmjieoechaddaejaokhf/assets/refined-github.js:4077:43)

Details

How to replicate the issue + URL
https://github.com/refined-github/refined-github/commits/main/
Extension version
24.6.21
Browser(s) used
Chrome Version 126.0.6478.127 (Official Build) (64-bit)

Thanks for the report! Fixed by https://github.com/refined-github/refined-github/pull/7495, not yet released