text:
index.html no such file error in instructions on "Creating a basic S2I builder image"

Hmm... another error I ran into.
[root@localhost wip]# s2i build test/ nginx-centos7 nginx-app
I0411 21:27:10.379144 04815 install.go:251] Using "assemble" installed from "image:///usr/libexec/s2i/assemble"
I0411 21:27:10.379206 04815 install.go:251] Using "run" installed from "image:///usr/libexec/s2i/run"
I0411 21:27:10.379219 04815 install.go:251] Using "save-artifacts" installed from "image:///usr/libexec/s2i/save-artifacts"
---> Building and installing application from source...
E0411 21:27:10.651792 04815 util.go:91] cp: cannot stat '/tmp/src/test/index.html': No such file or directory
E0411 21:27:12.349268 04815 main.go:357] An error occurred: non-zero (13) exit code from nginx-centos7

i believe that is output from your assemble script.  running with --loglevel=5 might reveal more.

[root@localhost wip]# s2i build test/ nginx-centos7 nginx-app
I0411 21:27:10.379144 04815 install.go:251] Using "assemble" installed from "image:///usr/libexec/s2i/assemble"
I0411 21:27:10.379206 04815 install.go:251] Using "run" installed from "image:///usr/libexec/s2i/run"
I0411 21:27:10.379219 04815 install.go:251] Using "save-artifacts" installed from "image:///usr/libexec/s2i/save-artifacts"
---> Building and installing application from source...
E0411 21:27:10.651792 04815 util.go:91] cp: cannot stat '/tmp/src/test/index.html': No such file or directory
E0411 21:27:12.349268 04815 main.go:357] An error occurred: non-zero (13) exit code from nginx-centos7
[root@localhost wip]# s2i build test/ nginx-centos7 nginx-app --loglevel=5
I0411 21:30:43.884068 04882 main.go:62] Running S2I version "v1.0.6"
I0411 21:30:43.887026 04882 docker.go:356] Using locally available image "nginx-centos7:latest"

Builder Name:			Nginx 1.6.3
Builder Image:			nginx-centos7
Source:				test/
Output Image Tag:		nginx-app
Incremental Build:		disabled
Remove Old Build:		disabled
Builder Pull Policy:		if-not-present
Previous Image Pull Policy:	if-not-present
Quiet:				disabled
Layered Build:			disabled
Docker Endpoint:		unix:///var/run/docker.sock

I0411 21:30:43.892773 04882 docker.go:356] Using locally available image "nginx-centos7:latest"
I0411 21:30:43.896995 04882 docker.go:356] Using locally available image "nginx-centos7:latest"
I0411 21:30:43.897013 04882 docker.go:476] Image contains io.openshift.s2i.scripts-url set to 'image:///usr/libexec/s2i'
I0411 21:30:43.897077 04882 scm.go:18] DownloadForSource test/
I0411 21:30:43.897107 04882 git.go:198] useCopy proto spec false local git repo false has git bin false
I0411 21:30:43.897113 04882 git.go:204] makePathAbsolute test/
I0411 21:30:43.897121 04882 git.go:207] makePathAbsolute new path /root/wip/test err <nil>
I0411 21:30:43.897125 04882 scm.go:25] return from ParseFile file exists true proto specified false use copy true
I0411 21:30:43.897128 04882 scm.go:32] new source from parse file /root/wip/test
I0411 21:30:43.897153 04882 sti.go:142] Preparing to build nginx-app
I0411 21:30:43.897403 04882 download.go:27] Copying sources from "/root/wip/test" to "/tmp/s2i781601864/upload/src"
I0411 21:30:43.897470 04882 fs.go:114] F "/root/wip/test/index.html" -> "/tmp/s2i781601864/upload/src/index.html"
I0411 21:30:43.897526 04882 install.go:251] Using "assemble" installed from "image:///usr/libexec/s2i/assemble"
I0411 21:30:43.897542 04882 install.go:251] Using "run" installed from "image:///usr/libexec/s2i/run"
I0411 21:30:43.897553 04882 install.go:251] Using "save-artifacts" installed from "image:///usr/libexec/s2i/save-artifacts"
I0411 21:30:43.897565 04882 ignore.go:58] .s2iignore file does not exist
I0411 21:30:43.897571 04882 sti.go:154] Clean build will be performed
I0411 21:30:43.897577 04882 sti.go:157] Performing source build from file:///root/wip/test
I0411 21:30:43.897580 04882 sti.go:168] Running "assemble" in "nginx-app"
I0411 21:30:43.897585 04882 sti.go:443] Using image name nginx-centos7
I0411 21:30:43.897592 04882 sti.go:447] No user environment provided (no environment file found in application sources)
I0411 21:30:43.897625 04882 sti.go:549] starting the source uploading ...
I0411 21:30:43.897633 04882 tar.go:193] Adding "/tmp/s2i781601864/upload" to tar ...
I0411 21:30:43.897719 04882 tar.go:260] Adding to tar: /tmp/s2i781601864/upload/src/index.html as src/index.html
I0411 21:30:43.899763 04882 docker.go:476] Image contains io.openshift.s2i.scripts-url set to 'image:///usr/libexec/s2i'
I0411 21:30:43.899779 04882 docker.go:530] Base directory for STI scripts is '/usr/libexec/s2i'. Untarring destination is '/tmp'.
I0411 21:30:43.899787 04882 docker.go:544] Setting "/bin/sh -c tar -C /tmp -xf - && /usr/libexec/s2i/assemble" command for container ...
I0411 21:30:43.899792 04882 docker.go:592] Creating container with options {Name:"" Config:&{Hostname: Domainname: User: Memory:0 MemorySwap:0 MemoryReservation:0 KernelMemory:0 CPUShares:0 CPUSet: AttachStdin:false AttachStdout:true AttachStderr:false PortSpecs:[] ExposedPorts:map[] StopSignal: Tty:false OpenStdin:true StdinOnce:true Env:[] Cmd:[/bin/sh -c tar -C /tmp -xf - && /usr/libexec/s2i/assemble] DNS:[] Image:nginx-centos7:latest Volumes:map[] VolumeDriver: VolumesFrom: WorkingDir: MacAddress: Entrypoint:[] NetworkDisabled:false SecurityOpts:[] OnBuild:[] Mounts:[] Labels:map[]} HostConfig:&{Binds:[] CapAdd:[] CapDrop:[] GroupAdd:[] ContainerIDFile: LxcConf:[] Privileged:false PortBindings:map[] Links:[] PublishAllPorts:false DNS:[] DNSOptions:[] DNSSearch:[] ExtraHosts:[] VolumesFrom:[] NetworkMode: IpcMode: PidMode: UTSMode: RestartPolicy:{Name: MaximumRetryCount:0} Devices:[] LogConfig:{Type: Config:map[]} ReadonlyRootfs:false SecurityOpt:[] CgroupParent: Memory:0 MemorySwap:0 MemorySwappiness:0 OOMKillDisable:false CPUShares:0 CPUSet: CPUSetCPUs: CPUSetMEMs: CPUQuota:0 CPUPeriod:0 BlkioWeight:0 Ulimits:[] VolumeDriver: OomScoreAdj:0}} ...
I0411 21:30:44.059463 04882 docker.go:623] Attaching to container "674d48f5b9124c74b023fcdde76c8610cc8060c77b6f302f9e5dfe503c817567" ...
I0411 21:30:44.059735 04882 docker.go:632] Starting container "674d48f5b9124c74b023fcdde76c8610cc8060c77b6f302f9e5dfe503c817567" ...
I0411 21:30:44.158929 04882 docker.go:656] Waiting for container "674d48f5b9124c74b023fcdde76c8610cc8060c77b6f302f9e5dfe503c817567" to stop ...
I0411 21:30:44.167667 04882 sti.go:583] ---> Building and installing application from source...
E0411 21:30:44.169365 04882 util.go:91] cp: cannot stat '/tmp/src/test/index.html': No such file or directory
I0411 21:30:44.243272 04882 docker.go:606] Removing container "674d48f5b9124c74b023fcdde76c8610cc8060c77b6f302f9e5dfe503c817567" ...
I0411 21:30:45.880137 04882 docker.go:610] Removed container "674d48f5b9124c74b023fcdde76c8610cc8060c77b6f302f9e5dfe503c817567"
I0411 21:30:45.880316 04882 cleanup.go:23] Removing temporary directory /tmp/s2i781601864
I0411 21:30:45.880328 04882 fs.go:156] Removing directory '/tmp/s2i781601864'
E0411 21:30:45.880541 04882 main.go:357] An error occurred: non-zero (13) exit code from nginx-centos7

seems like an error in the assemble example script
cp -Rf /tmp/src/index.html /usr/share/nginx/html/index.html
I'll send in a patch.

i'm not sure where your "test" directory came from, but the issue is that you passed "test/" as your repo, so s2i created working directory consisting of "/tmp/src/test/....."
if you want it to just work as is, cd into test and run "s2i build . nginx-centos7 nginx-app" instead, then you will have a "/tmp/src/...." and the assemble script will find the file.

the example has a test folder where you put in your code.  So I'm just following it.

I think we're say same thing, I just wanted to match the example project to the readme.

i'm actually wondering if we have a regression in how we are handling the path "test/" because the change to the assemble script shouldn't be necessary (it's not really the right fix for the problem you hit).  i'll need to dig into this a little more.

nm, you're right, the assemble script was just broken, thanks for the fix!

authors: alberttwong bparees

repo: openshift/source-to-image


text:
Can not go get

Trying to install with go get fails with :
$  go get github.com/openshift/source-to-image/cmd/s2i
go: finding github.com/openshift/source-to-image/cmd/s2i latest
go: finding github.com/openshift/source-to-image/cmd latest
go: finding github.com/openshift/source-to-image v1.1.13
go: downloading github.com/openshift/source-to-image v1.1.13
go: extracting github.com/openshift/source-to-image v1.1.13
go: finding github.com/golang/glog latest
go: finding github.com/spf13/pflag v1.0.3
go: finding github.com/docker/distribution/reference latest
go: downloading github.com/golang/glog v0.0.0-20160126235308-23def4e6c14b
go: extracting github.com/golang/glog v0.0.0-20160126235308-23def4e6c14b
go: downloading github.com/spf13/pflag v1.0.3
go: extracting github.com/spf13/pflag v1.0.3
go: finding github.com/docker/go-connections/tlsconfig latest
go: finding github.com/spf13/cobra v0.0.3
go: finding github.com/docker/go-connections v0.4.0
go: downloading github.com/spf13/cobra v0.0.3
go: extracting github.com/spf13/cobra v0.0.3
go: downloading github.com/docker/go-connections v0.4.0
go: extracting github.com/docker/go-connections v0.4.0
go: finding golang.org/x/net/context latest
go: finding golang.org/x/net latest
go: downloading golang.org/x/net v0.0.0-20190328230028-74de082e2cca
go: extracting golang.org/x/net v0.0.0-20190328230028-74de082e2cca
go: finding github.com/docker/docker/api/types/container latest
go: finding github.com/docker/docker/pkg/jsonmessage latest
go: finding github.com/docker/docker/api/types/network latest
go: finding github.com/docker/docker/api/types latest
go: finding github.com/docker/docker/pkg/stdcopy latest
go: finding github.com/docker/docker/client latest
go: finding github.com/docker/docker/cli/config latest
go: finding github.com/docker/distribution v2.7.1+incompatible
go: downloading github.com/docker/distribution v2.7.1+incompatible
go: extracting github.com/docker/distribution v2.7.1+incompatible
go: finding github.com/docker/docker/pkg latest
go: finding github.com/docker/docker/api latest
go: finding github.com/docker/docker v1.13.1
go: finding github.com/docker/docker/cli latest
go: downloading github.com/docker/docker v1.13.1
go: extracting github.com/docker/docker v1.13.1
go: finding golang.org/x/text v0.3.0
go: finding golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2
go: finding golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a
go: finding github.com/docker/go-units v0.3.3
go: finding github.com/opencontainers/go-digest v1.0.0-rc1
go: finding github.com/pkg/errors v0.8.1
go: downloading github.com/docker/go-units v0.3.3
go: extracting github.com/docker/go-units v0.3.3
go: downloading github.com/opencontainers/go-digest v1.0.0-rc1
go: extracting github.com/opencontainers/go-digest v1.0.0-rc1
go: downloading github.com/pkg/errors v0.8.1
go: extracting github.com/pkg/errors v0.8.1
build github.com/openshift/source-to-image/cmd/s2i: cannot load github.com/docker/docker/cli/config: cannot find module providing package github.com/docker/docker/cli/config

fresh 1.12.1 install with gvm
$  go version
go version go1.12.1 darwin/amd64

on macos mojave
$  system_profiler SPSoftwareDataType
Software:

    System Software Overview:

      System Version: macOS 10.14.4 (18E226)
      Kernel Version: Darwin 18.5.0

is this a docker rename to moby thing ?

is there a namespace change ?
https://github.com/docker/cli/blob/master/cli/config/config.go

I was able to successfully go get using gvm + go1.12.1 on Fedora 29.
You might try just cloning it into the correct location within your GOPATH and building it manually.
I know that doesn't solve your go get issue, but it will get you up and running at least.

thank you, I actually just installed it with brew and began using.
So this is not a stopper for me, but I thought I would bring it up.

source: gharchive/issue

license_type: permissive

license_source: github-api


text:
Removing non existing pkgs

Based on the mail conversation with @bparees
PTAL

thanks @jhadvig

source: gharchive/pull-request

authors: bparees jhadvig

repo: openshift/sti-base

license_source: bigquery


text:
🛑 Weblate is down

In 27c6938, Weblate (https://translate.opensourcepos.org) was down:

HTTP code: 500
Response time: 1000 ms

Resolved: Weblate is back up in 40d041e after 12 minutes.

repo: opensourcepos/upptime

license: MIT


text:
🛑 Dev is down

In 8bce358, Dev (https://dev.opensourcepos.org) was down:

HTTP code: 500
Response time: 355 ms

Resolved: Dev is back up in 94cb59a.


text:
Fix UI

[ ] Modify gap value to 16px

[ ] Homepage
[ ] List pages
[ ] Detail pages

Homepage

List pages

Detail pages

[ ] Modify the ui of time column in Transfer table

Figma link
Preview

[ ] Modify all the width of time cell column to 200px

Link
Preview

[ ] Modify all the width of identity/address column to 200px
[ ] Truncate text with ellipsis if the identity is overflow

Preview

[ ] Elements alignment

Link
Preview

[ ] Fix the color of date time in status cell to textTertiary

preview

[ ] Fix the width of time column in burn table to 200px

Preview

repo: opensquare-network/dotreasury


text:
[WIP] updating mapbox dependency and adding location/storage permissions

IMPORTANT: Where possible all PRs must be linked to a Github issue
Fixes https://github.com/opensrp/fhircore/issues/2936
Engineer Checklist

[ ] I have written Unit tests for any new feature(s) and edge cases for bug fixes
[ ] I have added any strings visible on UI components to the strings.xml file
[ ] I have updated the  CHANGELOG.md file for any notable changes to the codebase
[ ] I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the project's style guide
[ ] I have built and run the FHIRCore app to verify my change fixes the issue and/or does not break the app
[ ] I have checked that this PR does NOT introduce breaking changes that require an update to Content and/or Configs? If it does add a sample here or a link to exactly what changes need to be made to the content.

Code Reviewer Checklist

[ ] I have verified Unit tests have been written for any new feature(s) and edge cases
[ ] I have verified any strings visible on UI components are in the strings.xml file
[ ] I have verifed the CHANGELOG.md file has any notable changes to the codebase
[ ] I have verified the solution has been implemented in a configurable and generic way for reuseable components
[ ] I have built and run the FHIRCore app to verify the change fixes the issue and/or does not break the app

Fix failing tests so we can merge this.

Closing as it is not needed anymore.

authors: aurangzaibumer ellykits

repo: opensrp/fhircore


text:
ANC details screen

IMPORTANT: Where possible all PRs must be linked to a Github issue
Fixes #286
Type
Choose one: (Feature)
Checklist

[ ] I have written Unit tests for any new feature(s) and edge cases for bug fixes
[x] I have added any strings visible on UI components to the strings.xml file
[ ] I have updated the  CHANGELOG.md file for any notable changes to the codebase
[x] I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the project's style guide
[x] I have built and run the fhircore app to verify my change fixes the issue and/or does not break the app

Pull Request Test Coverage Report for Build #355

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 45.286%

Totals

Change from base Build #352:
0.0%

Covered Lines:
317

Relevant Lines:
700

💛  - Coveralls

@ellykits please review this PR.

authors: RaaziaTarique coveralls


text:
xml sitemap reference permission

https://github.com/parcel-bundler/website/blob/v2/src/languages/xml.md

Please stop playing around in our repository, or we will have to block you.
You can create your own repositores under your own account to experiment and play without disturbing others,

Thanks for responding .
AriesTriputranto
Pada tanggal Sen, 18 Apr 2022 06.09, Matthias St. Pierre <
@.***> menulis:

Please stop playing around in our repository, or we will have to block you.
You can create your own repositores under your own account to experiment
and play without disturbing others,
—
Reply to this email directly, view it on GitHub
https://github.com/openssl/openssl/issues/18126#issuecomment-1100964546,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AYC56HTSIIRQZPAE5JXIBMTVFSK2ZANCNFSM5TUHLIKQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

repo: openssl/openssl


text:
zlib-compressed certificates aren't interoperable

I'm testing newly merged certificate compression feature,
and I suspect that zlib-compressed data comes out malformed and non-interoperable.
OpenSSL is master, configured with no-shared enable-brotli enable-zstd enable-zlib.
I've tested it against:

gnutls client against openssl server
my implementation of RFC8879 in tlslite/tlsfuzzer

Rough steps to reproduce:
wireshark &
./apps/openssl s_server -www -key server/key.pem -cert server/cert.pem -verify 1 -CAfile ca/cert.pem -cert_comp &
SSLKEYLOGFILE=keylogfile build/src/gnutls-cli localhost:4433 --x509cert client/cert.pem --x509key client/key.pem --x509ca ca/cert.pem --compress-cert=zlib -d9

openssl prints 804BB240F37F0000:error:0A000412:SSL routines:ssl3_read_bytes:ssl/tls alert bad certificate:ssl/record/rec_layer_s3.c:783:SSL alert number 42
gnutls prints
...
|<3>| ASSERT: ../../lib/buffers.c[get_last_packet]:1176
|<3>| ASSERT: ../../lib/handshake.c[_gnutls_recv_handshake]:1600
|<3>| ASSERT: ../../lib/buffers.c[_gnutls_handshake_io_recv_int]:1428
|<3>| ASSERT: ../../lib/compress.c[_gnutls_decompress]:231
|<3>| ASSERT: ../../lib/tls13/certificate.c[decompress_certificate]:641
|<3>| ASSERT: ../../lib/tls13/certificate.c[_gnutls13_recv_certificate]:84
|<5>| REC: Sending Alert[2|42] - Certificate is bad
|<5>| REC[0x1a11bc0]: Preparing Packet Alert(21) with length: 2 and min pad: 0
|<9>| ENC[0x1a11bc0]: cipher: AES-256-GCM, MAC: AEAD, Epoch: 1
|<5>| REC[0x1a11bc0]: Sent Packet[1] Alert(21) in epoch 1 and length: 24
|<3>| ASSERT: ../../lib/handshake-tls13.c[_gnutls13_handshake_client]:124
*** Fatal error: Decompression of the TLS record packet has failed.
...

Moreover, if I select Compressed Certificate Message from Server Hello in wireshark,
export it and try to uncompress it with python's zlib, that fails:
import zlib
data = \
b"\x78\x9c\x62\x60\x60\x53\x65\x60\xe6\x37\x68\x62\xe6\x36\x68\x62" \
b"\xfc\xbc\x80\x99\x89\x91\x09\x88\x0c\x78\xd9\x38\xb5\xda\x3c\xda" \
b"\xbe\xf3\x32\x32\x72\xb3\x32\x18\x88\x1a\x0a\x1b\x08\xb2\x31\x87" \
b"\xb2\x70\xf1\x70\xb9\x56\x24\xe6\x16\xe4\xa4\x2a\x38\x3b\x1a\xc8" \
b"\x89\xf3\x1a\x19\x19\x1a\x18\x19\x18\x9a\x18\x1b\x1a\x5b\x46\x01" \
b"\xb9\xc6\x48\x5c\x03\x11\x43\x21\x03\x01\x90\x36\x66\x1e\xce\x9c" \
b"\xfc\xe4\xc4\x9c\x8c\xfc\xe2\x12\xa0\x3d\x4a\xc8\xe6\x33\xb2\x32" \
b"\x30\x37\x31\xf2\x33\x00\xc5\xb9\x98\x9a\x18\x19\x19\xf6\xda\x5f" \
b"\x72\xfd\x70\xa7\x62\xfe\xb9\xe7\x9f\xda\xf4\xa5\xa3\x76\x1b\x1c" \
b"\xbe\x5a\x2d\x96\x53\x1d\xce\x7c\xf4\x57\x1b\x23\x67\x64\xcd\x8d" \
b"\x25\x65\x65\x45\x2d\xae\x99\x21\xfb\x26\x4c\xcc\x5e\xb1\xab\xbd" \
b"\xe0\x5e\xc2\x04\xa9\x57\x87\xe2\xf2\xe6\x4f\x55\x37\xf4\xce\xb3" \
b"\xdf\x9f\xe8\xb6\xc0\xe0\xf0\xa9\x5d\x11\xd3\xa3\xcf\x2d\xfe\x37" \
b"\x7f\xcf\xf4\x1f\xde\x33\xdc\xbb\x55\x93\x9d\xe7\x5e\x92\x98\xa4" \
b"\x2b\x31\x35\xde\x85\xdb\x4e\x42\x71\xa3\x82\x93\x98\xf1\x5e\xab" \
b"\x43\x3d\xf7\xdf\xdf\x99\xbf\x8f\xe5\xf7\x61\xf1\xd5\x6d\xad\x0f" \
b"\x8f\x58\xa9\xcd\xf7\xfc\x3c\xe1\xc2\x04\xe9\x7b\x56\x8f\xd6\x37" \
b"\xa7\x34\x2e\x97\xbe\x64\x6b\xba\x44\x93\x49\x69\x41\xb2\xc2\x86" \
b"\x97\x36\x93\x6c\x3e\xd8\x73\x76\xb6\xf7\x26\x88\x07\x4f\x28\xb6" \
b"\x63\x99\xe5\xc9\xbc\xe9\xb0\xff\x85\xd5\x4f\x3c\x3e\x5a\x71\x5f" \
b"\xfd\xc3\xc2\xd3\x7f\x85\x43\xd7\xc6\xe6\xdf\xf5\x0d\xd3\xfe\xd6" \
b"\xdc\xf1\x8b\x53\x69\x31\xf1\xda\xb1\xda\xc4\x36\x26\x4f\x7e\xba" \
b"\x49\x80\xc3\xfc\xba\x5b\x7d\x3a\xbb\xed\xb2\xbf\x29\x05\x34\xc4" \
b"\x1d\x6e\x4b\x34\xd0\xec\x33\xe9\x08\x52\x9a\x6c\xbc\x40\x34\xad" \
b"\xfc\xd8\xb4\x07\xbf\x25\x42\x33\xd5\x55\x99\x98\x19\x19\x18\x17" \
b"\xa7\x1b\xa4\x1a\xf0\x01\xc3\x4e\x96\x9f\x91\xf1\x3f\x0b\x0b\x33" \
b"\x13\xf3\x0a\x03\x61\x10\x5f\x95\x85\xc7\x80\x8b\x8d\x43\x9b\x8d" \
b"\x91\x95\x95\x9d\x99\xd1\x40\x16\x24\xc8\xc7\x22\xc6\x22\x32\x47" \
b"\x6e\x95\x7d\xc1\xff\x33\x7b\xfa\x82\x32\x66\x96\xf5\x88\x2a\xf8" \
b"\x24\x24\x3c\x33\x90\x07\x49\x2b\xb3\x48\x18\x88\x35\x88\xdc\xe8" \
b"\xba\xb6\x80\xe1\xfd\xd1\x99\x4b\x1f\xa5\xf9\x9c\xe8\x4d\xae\x09" \
b"\xa9\x3d\xbf\x08\x2d\xaa\x99\x41\x31\x50\x15\xd0\x75\x6f\xd9\x35" \
b"\xc5\xa7\xe7\x66\x5b\x71\x33\xd7\x5d\x58\x28\x1c\x76\xe5\x7f\xa8" \
b"\xd4\xe2\x65\x33\xbf\x0a\x19\xd8\xef\x91\xdb\xbc\x58\x76\xe5\x19" \
b"\x95\xbd\x4f\xf3\x8f\x6b\x3a\x1a\xe6\xab\xa7\xeb\x95\x1f\x17\x88" \
b"\x70\xd4\x3a\xbc\xa0\xf0\xe9\x92\x4f\x59\x2c\x3b\xc3\x6f\xeb\xdd" \
b"\x58\xf6\xf3\xe4\xe1\xbf\x8b\x04\x94\xfe\x1c\x0b\xbf\x7c\xaa\x54" \
b"\xfe\xdc\xb5\xb4\x4c\x19\xc6\xf5\x3b\xd6\xb0\xaf\x99\x1b\x5a\x7b" \
b"\x96\xd9\x95\x53\x9b\x29\x7d\x65\xe1\xf2\x7f\x0e\xdf\x1f\x2b\x58" \
b"\xe6\x65\xb7\x8a\x75\x9e\x58\x14\xa9\xe5\xb4\x7d\xeb\xef\xb5\xb7" \
b"\x63\xa6\x2d\xcc\x4f\x58\xb1\xc2\x47\xba\xd9\xbd\xc2\x2f\xde\xfa" \
b"\xcb\xc4\x95\xdd\x53\xd5\x2d\x0f\x94\x64\xfe\x75\x8d\x99\x12\x1e" \
b"\x58\xed\x62\xda\x5a\x91\xd5\x32\x55\x6d\xfd\xe9\x49\x9d\xd6\x66" \
b"\x0b\x35\x3a\xfb\x27\x5c\x5c\x2c\x52\x31\xe9\x89\xd0\xd6\x5f\xcd" \
b"\x09\x4f\x3d\xc5\xdd\x37\xc9\x9c\xe5\x5c\xf4\x2f\xc5\x7f\x76\x8e" \
b"\xeb\xea\x2d\xd3\xdf\xaa\xaf\x33\xb1\xbb\xcc\x15\x9a\x57\xbe\xf1" \
b"\x6e\x5a\xfe\x36\x0f\xfd\xe4\xfa\x43\x8a\x3f\xee\xc7\x55\x7f\xd4" \
b"\xaa\xcf\xf6\x8d\x8f\xe7\xfa\x26\x68\x71\xc9\xc2\x7f\xc1\x29\xcf" \
b"\x1d\xae\x5b\xff\xf8\x6f\x3b\xc5\xc0\xc0\xc0\xcc\x03\xcc\x13\x1c" \
b"\xc0\x34\xf9\x01\x9a\x27\x18\x89\xcf\x13\x86\xe6\xf0\x4c\x60\x00" \
b"\xcc\x13\xc6\x46\x48\x5c\x5c\xda\x08\x65\x8a\x65\x1d\xe7\x7d\x2c" \
b"\x97\x6e\x77\x63\xcf\x5f\xfc\x81\x67\xd2\xc2\xbc\x49\x1a\xce\x4f" \
b"\xd5\xfb\xb4\x32\x33\xb6\x67\x18\x4d\x6f\xeb\x91\x69\x9e\xf7\xca" \
b"\x77\x53\xde\xd2\xc8\x25\x1d\x5e\x4c\xb3\x17\x96\x27\x3a\x3e\xbb" \
b"\xce\x7a\x7a\xe3\xab\xd9\x6a\x3f\x42\xd8\x8e\x32\xe5\xaf\x3b\xf4" \
b"\xea\x4c\x56\x6d\xde\xfb\xf2\x4c\x4d\xa3\xce\x46\x23\x31\x91\x15" \
b"\xaa\xdb\xa6\x25\xcc\x11\x28\x6f\xac\x4b\xb2\x4d\x9f\xbc\xae\x58" \
b"\xe5\x40\x95\x01\x5b\x66\x56\xd5\xc3\xc3\xfe\x26\xb7\xf5\x65\x3d" \
b"\xd5\xb9\x39\xa7\xef\xcd\x48\xe7\x8e\xfd\x6c\x63\x31\x7f\x12\x8b" \
b"\xe1\x31\xfd\x88\xf2\x4b\x92\xeb\x66\xcd\xc8\xdd\xb9\x79\x73\xe8" \
b"\xa2\x90\x82\x65\xd7\xbb\x2a\xec\x6f\xbf\xb0\xd6\x7c\xe0\x9f\xb1" \
b"\xf0\xa4\xe2\x47\xd6\x06\xbf\xba\xa7\x95\x05\xf2\xba\xaa\x99\xc6" \
b"\xbc\x6b\x2b\x3b\xb9\xd9\x1f\xfd\x0e\xb2\x33\x3d\xfa\xd8\x48\xac" \
b"\x3b\xd2\xb5\xe7\x64\x6a\x4c\xf2\x81\x1d\x9b\x03\x12\xfc\x13\x5f" \
b"\x78\xab\x65\x9f\x5b\xf4\x46\x5b\xdf\x50\xf0\x88\x59\x4e\x3d\xc3" \
b"\xe9\x57\x1f\xf8\x9d\xbd\x2b\x0e\xb3\xb3\xa6\x0a\xf8\xeb\x3c\x8b" \
b"\x6b\x3f\x97\xfe\x80\x81\xef\xf1\xec\x0f\x97\xfc\xac\xb8\xa2\xf9" \
b"\x1b\x5c\x65\xfd\xa5\x03\x21\x99\x22\xd9\x20\xd1\x80\x1f\x94\xa0" \
b"\x85\x41\x99\x82\xd5\x80\x19\x48\xa1\xe6\x12\x46\x36\xa4\x0c\x81" \
b"\x35\xbd\x93\x93\x21\x84\x9d\x27\xef\x15\x12\xd9\x1d\x7e\x4a\xc5" \
b"\x78\x52\x9c\xcf\x96\x0b\x1c\xe7\xbf\xbf\x2f\x67\xd7\xab\x29\x5d" \
b"\xb4\x2b\xf3\xc7\xb2\xbc\x1d\x7a\xce\xcc\x5f\x36\x7b\x38\x86\xf5" \
b"\x54\x59\x7b\xa5\x9e\xe1\xf3\xbd\x69\x95\xb0\xe9\x9a\x9f\xd2\xe1" \
b"\xf0\x13\x8e\x97\xb8\x7e\xf9\x7b\xc8\x2e\x38\x73\xf6\xdd\xc4\xd8" \
b"\x84\x7b\xe9\x56\xdc\xa5\x02\x6e\x87\xaa\x13\xa6\x3b\xbc\xe1\x6b" \
b"\x48\x7f\xca\xfd\x74\x2e\xc3\x56\xfe\x04\xf6\x39\xb5\xdd\x87\x52" \
b"\xbf\x36\xda\x70\x2b\x5c\x5c\xc3\xaf\xe6\xad\x16\xfa\x2c\xd8\x3c" \
b"\x87\xc3\x99\xab\x2f\xf9\xed\xed\xc3\xdb\xee\x16\xec\x66\xf5\xcc" \
b"\x5c\xa8\xbb\xf6\x93\x60\xee\xe3\x46\x87\x0b\x09\x8b\x9a\x9b\xde" \
b"\xd9\x85\x85\x2e\x79\x1a\xfe\xaa\x98\x6b\x49\xa6\x5d\x22\xff\xf3" \
b"\xe4\x58\x9b\x65\x57\x2f\xfe\x15\x9b\x1d\xba\xf7\x53\xf2\xdc\x85" \
b"\xb3\x7f\xbd\x4b\x4a\x6f\xd8\xcf\x76\x77\x5f\xa7\xf3\xe4\x9b\xba" \
b"\xfd\x45\x13\x45\x72\x0c\xd7\x7a\x4e\xbf\xa7\x97\xbf\xe9\xac\x85" \
b"\x74\x87\x75\xed\x84\xef\x5a\x41\xb3\xd3\x66\xcc\x0d\xda\xaa\xe5" \
b"\xb1\xbf\xef\xc6\xdf\x33\xcb\xdf\x72\x9e\x9c\xbe\x6f\x15\xab\x47" \
b"\xfc\xaf\x0e\xdb\x3b\xbb\xc4\xb2\x26\x6c\x0e\x2a\x3c\xa6\x1c\x51" \
b"\x70\x96\x93\x81\x01\x00\x00\x00\xff\xff"
zlib.decompress(data)

zlib.error: Error -5 while decompressing data: incomplete or truncated stream

Note that without a -comp_cert on the server, compression isn't used at all,
I'm not sure this is intended.
If you'd like me to provide a more complete self-contained reproducer,
please specify what implementation would you prefer me to reproduce against.

@tmshort could you please look?

I'll take a look when I get a chance.
Is it only with ZLIB? What about Brotli and Zstd?

Note that without a -comp_cert on the server, compression isn't used at all,
I'm not sure this is intended.

That's intentional, you have to explicitly tell it to compress the certificate on the server-side (so it can be tested as "enabled", but with no compressed certificates).

Is it only with ZLIB? What about Brotli and Zstd?

Yes, the other two decompressed fine in my testing.

Note that without a -comp_cert on the server, compression isn't used at all, I'm not sure this is intended.

That's intentional, you have to explicitly tell it to compress the certificate on the server-side (so it can be tested as "enabled", but with no compressed certificates).

--help said it's "pre-compress", SSL_CONF_cmd said compression is on by default and s_client lacked a matching option, so I was left under the impression it precompresses server certs. Like, performs an optimization, not acts as a knob for everything RFC8879.

There's a few things going on here. The API went through several iterations during review. It was decided to simplify and always have the server-side pre-compress the certificates, rather than enable automatic compression, which is what the client does.
This was done for performance, to avoid repetitively compressing a certificate on-the-fly when it's not necessary. This is possible on the server-side only, since the context value is 0. This allows an application to call the pre-compression APIs and store the pre-compressed certificate in an SSL_CTX or other data store.
For the client-side, since the context value is given to it by the server, the compression has to be done on demand during the handshake.
That being said, we have to distinguish between the options that are available to enable/disable certificate compression via the extension, and the actual use of a compressed certificate.
The negotiation of the certificate compression option is enabled by default. The SSL_OP_NO_TX_CERTIFICATE_COMPRESSION and SSL_OP_NO_RX_CERTIFICATE_COMPRESSION options (and their corresponding configuration file commands) can be used to enable and disable this negotiation.
In actuality, this is not a negotiation, the extension is just a notification from one peer to the other indicating what types of certificate compression it supports.
Now, just because certificate compression is supported by the peer, it doesn't mean it has to be used! For example, if the compressed certificate actually expands, sending this larger certificate makes no sense. Or maybe one side doesn't support a compression algorithm the peer does.
So, the -comp_cert option on the server is used to invoke the APIs to pre-compress the certificates in s_server.
This extra knob allows testing with s_server, in that you are able to control whether or not to actually have the server send a compressed certificate based on the "negotiation".
For instance, if I want to test if my client's state machine can handle the non-compressed Certificate message even though my client sent the extension.
(I worked on this PR for 3 years, so I can elaborate on it quite a bit.)

In response specifically to this:

Like, performs an optimization, not acts as a knob for everything RFC8879.

To sent compressed certificates from the server, the certificates must always be pre-compressed; it's not considered an optimization (even though it is). This was to actually simplify the user API, since there was originally a complicated callback mechanism and multiple means of compressing the certificate.
Given a CDN for example, which might store and transport certificates around its network already compressed, it just needs to assign the compressed blob to the SSL/SSL_CTX via the SSL_set1_compressed_cert() (or SSL_CTX version) API after loading the non-compressed certificate and key.
A simpler website would instead load the certificate and key, then call SSL_CTX_compress_certs() to automatically compress the certificates (this is basically what -comp_cert does).

Is it only with ZLIB? What about Brotli and Zstd?

Yes, the other two decompressed fine in my testing.

Thank you, this is helpful.

I summarized several more useful features in #19532

Looks as though I have to add a zlib oneshot function that terminates/completes the compression properly.
@t184256 could you try this branch? https://github.com/tmshort/openssl/tree/fix-zlib

@tmshort, thumbs up. Tried that one, zlib-compressed data is now decompressable.

authors: beldmit t184256 tmshort


text:
error:0A000458:SSL routines::tlsv1 unrecognized name

OpenSSL version: 3.0.8-1 (arch linux)
Trying to add OpenSSL to a valid socket causes error:0A000458:SSL routines::tlsv1 unrecognized name
std::string Frame::send_request(const std::string& host, const std::string& request) {
    int sockfd = socket(AF_INET, SOCK_STREAM, 0);
    if (sockfd < 0) throw std::runtime_error("error opening socket");

    struct timeval tv{5};
    setsockopt(sockfd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof tv);

    auto server = gethostbyname(host.c_str());
    if (server == nullptr) throw std::runtime_error("error no such host");

    sockaddr_in serv_addr{};
    serv_addr.sin_family = AF_INET;
    serv_addr.sin_port = htons(443);
    memcpy(&serv_addr.sin_addr.s_addr, server->h_addr, server->h_length);

    if (connect(sockfd, reinterpret_cast<const sockaddr *>(&serv_addr), sizeof(serv_addr)) < 0) {
        throw std::runtime_error("error connecting to socket");
    }

    SSL_load_error_strings();
    SSL_library_init();
    SSL_CTX *ssl_ctx = SSL_CTX_new (SSLv23_client_method());
    SSL *conn = SSL_new(ssl_ctx);
    SSL_set_fd(conn, sockfd);

    if (SSL_connect(conn) < 1) throw std::runtime_error(ERR_error_string(ERR_get_error(), nullptr));

    size_t total = request.length();
    size_t sent = 0;

    while (sent < total) {
        ssize_t bytes = SSL_write(conn, request.c_str() + sent, total - sent);
        if (bytes < 0) throw std::runtime_error("error writing message to socket");
        sent += bytes;

        std::cout << "Sent " << sent << " out of " <<  total << " bytes \n";
    }

    std::string response;
    ssize_t received = 0;

    while (true) {
        char buf[BUF_SIZE];
        ssize_t bytes = SSL_read(conn, buf, BUF_SIZE);

        if (bytes < 0) throw std::runtime_error("error reading response from socket");
        if (bytes == 0) break;

        received += bytes;
        response.append(buf, bytes);
    }

    SSL_shutdown(conn);
    SSL_free(conn);
    close(sockfd);

    return {response.begin(), response.end()};
}

This means that the server send an "unrecognized name" alert back to your client. Typically this will be because it doesn't like the SNI data you provided, or you didn't provide any and it requires it.
You should probably call SSL_set_tlsext_host_name() prior to calling SSL_connect() to set the SNI hostname you are connecting to. Also recommended is a call to SSL_set1_host() to configure the certificate hostname check.
See the following for example client and server code:
https://github.com/openssl/openssl/blob/master/demos/sslecho/main.c


text:
[rt.openssl.org #3846] openssl 1.0.2 shared build's linking is not consistent - bin and libs linked to different libcrypto.so's

Migrated from rt.openssl.org#3846 (status was 'new')
Requestors:

h15234@mailas.com

From h15234@mailas.com on 2015-05-12 17:53:12:
trying to build a library self-consistent instance of openssl 1.0.2 on linux/64.

 Setting *FLAGS & rpath, although the openssl binary links correctly against its own {libcrypto,libssl}.so, the libssl.so links against *system*, not its own, libcrypto.

 I've tried a bunch of combinations of *FLAGS.  Always the same result.  The current env/result is:

 	cd ./openssl-1.0.2

 	export SHARED_LDFLAGS="-L/usr/local/sslTEST/lib64 -Wl,-rpath,/usr/local/sslTEST/lib64 -lssl -lcrypto"
 	export LDFLAGS=${SHARED_LDFLAGS}
 	export LIBDEPS=${SHARED_LDFLAGS}

 	./config \
 	 --openssldir=/usr/local/sslTEST \
 	 --libdir=lib64 \
 	threads shared zlib \
 	enable-ec_nistp_64_gcc_128 \
 	no-idea \
 	no-ssl2 \
 	no-rc5 \
 	no-mdc2 \
 	no-hw \
 	no-ec2m \
 	enable-rfc3779

 	make depend
 	make
 	make install

 There are no apparent errors in the build output.

 The build results in

 	/usr/local/sslTEST/bin/openssl version
 		OpenSSL 1.0.2 22 Jan 2015

 	ldd \
 	 /usr/local/sslTEST/bin/openssl \
 	 /usr/local/sslTEST/lib64/libssl.so.1.0.0 \
 	 /usr/local/sslTEST/lib64/libcrypto.so.1.0.0

 		/usr/local/sslTEST/bin/openssl:
 			linux-vdso.so.1 (0x00007ffefffd7000)
 			libssl.so.1.0.0 => /usr/local/sslTEST/lib64/libssl.so.1.0.0 (0x00007f93cbe0e000)
 !!			libcrypto.so.1.0.0 => /usr/local/sslTEST/lib64/libcrypto.so.1.0.0 (0x00007f93cb9ce000)
 			libdl.so.2 => /lib64/libdl.so.2 (0x00007f93cb77f000)
 			libz.so.1 => /lib64/libz.so.1 (0x00007f93cb569000)
 			libc.so.6 => /lib64/libc.so.6 (0x00007f93cb1c1000)
 			/lib64/ld-linux-x86-64.so.2 (0x00007f93cc07a000)

 		/usr/local/sslTEST/lib64/libssl.so.1.0.0:
 			linux-vdso.so.1 (0x00007ffd01636000)
 !!			libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x00007ff4abf33000)
 			libdl.so.2 => /lib64/libdl.so.2 (0x00007ff4abd2f000)
 			libz.so.1 => /lib64/libz.so.1 (0x00007ff4abb18000)
 			libc.so.6 => /lib64/libc.so.6 (0x00007ff4ab771000)
 			/lib64/ld-linux-x86-64.so.2 (0x00007ff4ac60d000)

 		/usr/local/sslTEST/lib64/libcrypto.so.1.0.0:
 			linux-vdso.so.1 (0x00007ffe1f55d000)
 			libdl.so.2 => /lib64/libdl.so.2 (0x00007f9a10f46000)
 			libz.so.1 => /lib64/libz.so.1 (0x00007f9a10d30000)
 			libc.so.6 => /lib64/libc.so.6 (0x00007f9a10988000)
 			/lib64/ld-linux-x86-64.so.2 (0x00007f9a115d5000)

 where you can see the different libcrypto's are linked.

a workaround is to just ignore it -- and fix the link AFTER the build's done.

Noting

	On Tue, Apr 7, 2015, at 07:06 PM, Jeffrey Walton wrote:
	> As far as I know, you only need an RPATH on Linux (OS X and Android
	> are a different story).

After the build, since there's no proper RPATH for the libssl.so with any combination of FLAGs that I've been able to figure out,

	ldd libssl.so.1.0.0 | egrep "ssl|crypto"
	        libcrypto.so.1.0.0 => /lib/libcrypto.so.1.0.0 (0x00007f55e46c0000)
	readelf --dynamic libssl.so.1.0.0 | egrep -i "rpath|runpath"
		(empty)

For anyone actually interested this does the trick

	patchelf --set-rpath "/path/to/ssl/lib" --force-rpath libssl.so.1.0.0
	readelf --dynamic libssl.so.1.0.0 | egrep -i "rpath|runpath"
		0x000000000000000f (RPATH)              Library rpath: [/path/to/ssl/lib]

	ldd libssl.so | egrep "ssl|crypto"
	        libcrypto.so.1.0.0 => /path/to/ssl/lib/libcrypto.so.1.0.0 (0x00007f476b4fc000)

This was closed because it's overtaken by events (1.1.0 has a unified build)?

if this is needed, and if static linking for the apps is not sufficient, someone will have to re-open the issue.

authors: kaduk richsalz


text:
RAND_DRBG uses uninitialized urandom read on linux

This message can be seen when openssl s_server is started early after reboot:
./openssl s_server
random: openssl: uninitialized urandom read (32 bytes read)
Using default temp DH parameters
ACCEPT

I have seen this with linux v4.18, and v4.14-stable.
Previous linux versions are also affected, but do not report the error.

This is not an error of openssl. Basically the kernel signals that the in-kernel CRNG was not yet fully initialized with sufficient entropy.

The point is, if we use /dev/urandom to initialize the DRBG the kernel tells us that the
returned random data is not good enough.
I think we should probably use /dev/random, and wait for enough entropy.

I assume this is done when we call the getrandom syscall.  According to the documentation I'm reading, the call we make should block until there's enough entropy, since we don't set the GRND_NONBLOCK flag:

       GRND_NONBLOCK
              By default, when reading from  the  random  source,  getrandom()
              blocks  if  no random bytes are available, and when reading from
              the urandom source, it blocks if the entropy pool  has  not  yet
              been  initialized.   If  the GRND_NONBLOCK flag is set, then ge‐
              trandom() does not block in these cases, but instead immediately
              returns -1 with errno set to EAGAIN.

Ahm, well....
Actually the used cross-compiler comes with a linux headers from 3.2.14, and glibc headers 2.15.
So if it does not define GRND_NONBLOCK and no getrandom syscall, what happens then?

My understanding is that the getrandom() system call is more or less equivalent to reading from /dev/urandom, whereas getentropy() corresponds to /dev/random.
However, there seems to be an important difference between getrandom() and /dev/urandom during early boot time: While getrandom() blocks until the initial seeding of the pool is complete, '/dev/urandom' according to RANDOM(4) never blocks.
   Usage
       The  /dev/random interface is considered a legacy interface, and /dev/urandom is preferred and sufficient in all use cases, with the exception
       of applications which require randomness during early boot time; for these applications, getrandom(2) must be used instead,  because  it  will
       block until the entropy pool is initialized.

       If  a seed file is saved across reboots as recommended below (all major Linux distributions have done this since 2000 at least), the output is
       cryptographically secure against attackers without local root access as soon as it is reloaded in the boot sequence,  and  perfectly  adequate
       for  network encryption session keys.  Since reads from /dev/random may block, users will usually want to open it in nonblocking mode (or per‐
       form a read with timeout), and provide some sort of user notification if the desired entropy is not immediately available.

So I would guess that OpenSSL was seeding from /dev/urandom, not from getrandom().

Okay, if the getrandom syscall is not available we seed from /dev/urandom and only if that
is not available use /dev/random, but it should be other way round.

So, how about that?
diff --git a/e_os.h b/e_os.h
index 9c0888e..461015a 100644
--- a/e_os.h
+++ b/e_os.h
@@ -28,9 +28,9 @@
  * default, we will try to read at least one of these files
  */
 #  if defined(__s390__)
-#   define DEVRANDOM "/dev/prandom","/dev/urandom","/dev/hwrng","/dev/random"
+#   define DEVRANDOM "/dev/random","/dev/prandom","/dev/urandom","/dev/hwrng"
 #  else
-#   define DEVRANDOM "/dev/urandom","/dev/random","/dev/srandom"
+#   define DEVRANDOM "/dev/random","/dev/urandom","/dev/srandom"
 #  endif
 # endif
 # if !defined(OPENSSL_NO_EGD) && !defined(DEVRANDOM_EGD)

Okay, if the getrandom syscall is not available we seed from /dev/urandom and only if that is not available use /dev/random, but it should be other way round.

I still don't think we should do this, we would hog the entropy pool by doing it. Just think of the OpenSSL testsuite where a lot of openssl instances are launched. If they all would be seeding from /dev/random (or getentropy(), you would be in trouble.
For the current Linux kernels the fact that getrandom() blocks until the initial seeding has completed should be sufficient. After that, the kernel CSPRNG is cryptographically secure, which is good enough, unless we are running in FIPS 3.0 mode (t.b.d.) and it is either the first seeding of the <master> DRBG, or prediction resistance was requested. (It is clear that the entropy gathering needs to be improved for FIPS and that we need distinction between blocking sources with entropy guarantuee and nonblocking sources).
As for older kernels without getrandom(): IMHO it is the job of the init system to save and restore a seed file across reboots, as recommended in the citation from RANDOM(4). So I wouldn't consider it an OpenSSL bug if this message occurs.

@kroeckx might know more about kernel CSPRNG details than I do.

How does this affect the answer I gave
to https://github.com/openssl/openssl/pull/8023#discussion_r256318746
I said: "If we let it fail here, the chances are that the caller of RAND_bytes does not check the
return code, or it does at least not have no good strategy to handle the error.
I would prefer to wait, unless it is a permanent error."
but I think VxWorks Randlib is working like /dev/random, just that it fails when no entropy
is immediatly available.

How does this affect the answer I gave to #8023 (comment)

It would be good to have more detailed information about the VxWorks randlib in general and the randBytes() call in particular, before answering this question. Is there any  official documentation available online or offline?
cc @klotzt-draeger

.. the chances are that the caller of RAND_bytes does not check the return code, or it does at least not have no good strategy to handle the error.

This is a really good question and I remember having discussed it with @kroeckx (IIRC) at some time:
Currently the DRBG refuses to generate random bytes if it is in the error state(*), so it is crucial to check the return value of RAND_bytes(). I asked Kurt whether it wouldn't be better to return an error and generate the requested random bytes regardless of the error state, just to be safe in the case where the application wouldn't check the error. But the conclusion was that it would be even worse, because we would provide fake security and the chance of detecting the failure would be less than if the RNG would'nt refuse to generate the output.
(*) The DRBG attempts an automatic error recovery by reseeding, but if that fails, it will remain in the error state.

Citing myself from RAND(7):
       As a normal application developer, you do not have to worry about any details,
       just use RAND_bytes(3) to obtain random data.  Having said that, there is one
       important rule to obey: Always check the error return value of RAND_bytes(3)
       and do not take randomness for granted.

getrandom() and getentropy() will always block until the kernel
CSPRNG has been initialized. If you have a kernel that supports
it, so >= 3.17, we should always use it. Only with an older kernel
should be fall back to using /dev/urandom.
I've actually had people report that the boot now hangs because of
this for some people, for instance openssh blocking until it can
get random data.
I don't think we should be using /dev/random at all. If
getrandom()/getentropy() is not available, /dev/random will
probably also do the wrong thing and cause things to hang, but
then hang all the time.
Reading 1 byte from /dev/random should also not be done by each
process. People that want to make sure that no application reads
from /dev/urandom before it's initialized should prevent those
applications from starting instead, by for instance reading 1 byte
during the boot process.

To actually be able to use getrandom on Linux if it's not provided
by glibc, you need to compile against recent enough kernel headers
so that SYS_getrandom is defined. Note that SYS_getrandom is
architecture specific.

For the current Linux kernels the fact that getrandom() blocks until the initial seeding has completed should be sufficient. After that, the kernel CSPRNG is cryptographically secure, which is good enough, unless we are running in FIPS 3.0 mode (t.b.d.) and it is either the first seeding of the <master> DRBG, or prediction resistance was requested. (It is clear that the entropy gathering needs to be improved for FIPS and that we need distinction between blocking sources with entropy guarantee and nonblocking sources).

According to the discussions I've had with the FIPS lab about entropy sources, this isn't correct.  Calling a blocking getrandom() system call is good enough for FIPS and is straightforward to justify.
If we need to use /dev/urandom, the only method I can think of to guarantee that it is properly seeded is via waiting for something like dd if=/dev/random of=/dev/urandom BS=32 count=1 iflag=fullblock  I.e. read bytes from the blocking source and feed them back into the RNG.
We should avoid /dev/random is we can, but we might not be able to do so.

+#   define DEVRANDOM "/dev/random","/dev/prandom","/dev/urandom","/dev/hwrng"

I'd put /dev/hwrng before /dev/prandom.  /dev/prandom is a pseudo random generator like /dev/urandom and I don't believe claims about made about it being properly seeded.

+#   define DEVRANDOM "/dev/random","/dev/urandom","/dev/srandom"

/dev/srandom should be before /dev/urandom and perhaps even before /dev/random.  It is a good source.

According to the discussions I've had with the FIPS lab about entropy sources, this isn't correct. Calling a blocking getrandom() system call is good enough for FIPS and is straightforward to justify.

That's good news. It seems that I was too pessimistic. :-)

Calling a blocking getrandom() system call is good enough for FIPS and is straightforward to justify.

What about prediction resistance? It was always Kurt's opinion (not mine) that a prediction resistance request needs to be propagated upwards. This would imply that in this case, getentropy() would be required to reseed.

Please do not ever use /dev/random in openssl by default. That would be simply not usable in any normal scenario where openssl is used throughout the system.

It is OS business to ensure that the kernel RNG is properly seeded with entropy on system boot, openssl has no way to influence/enforce that. To summarize - use getrandom/getentropy (without GRND_RANDOM flag of course) and if it is not available, use /dev/urandom. That's it.

@t8m I quite agree.

getrandom() should stir in more entropy if any is available, i.e. it isn't a pure PRNG.  Of course, it would always be better to guarantee new entropy has been added.
The problem with /dev/urandom, in the context of the FIPS project, is the justification that it has been adequately seeded.  Once it has been seeded, it's fine but until you can prove that, it isn't acceptable.  In FIPS mode we might be forced to used /dev/random in the absence of getrandom() and getentropy() system calls.  Outside of FIPS mode, I can't see this ever being mandated.

I think this does probably not do what was intended:
openssl-1.1.1a/crypto/rand/rand_unix.c:#  if defined(__linux) && defined(SYS_getrandom)
openssl-1.1.1a/crypto/rand/rand_unix.c:    return syscall(SYS_getrandom, buf, buflen, 0);

... because linux defines __NR_getrandom and glibc defines SYS_getrandom.
So glibc before 2.16 will not define SYS_getrandom regardless of the linux version.

Do not ever use /dev/random ... that is unacceptable

@t8m please explain this?

... because linux defines __NR_getrandom and glibc defines SYS_getrandom.
So glibc before 2.16 will not define SYS_getrandom regardless of the linux version.

Update:
The glibc 2.25 was the first to implement the getrandom function, but I tried to build
glibc 2.24 against the current linux headers, and it did define the SYS_getrandom.
But this define will not be created when the linux headers are updated afterwards.
It would still make sense to use the linux define __NR_getrandom directly, IMHO.

Do not ever use /dev/random ... that is unacceptable

@t8m please explain this?

Apart from the obvious blocking?

Yes, we should use __NR_getrandom.

If my memory is correct, FIPS says that using the OS provided
entropy is fine, it does not talk about which interface you talk
to the OS. I don't see why FIPS should care about /dev/urandom vs
getrandom(), other than that Linux's /dev/urandom is broken and
returns data before it has been initialized. But I think making
sure that is initialized is up to the OS, not OpenSSL.

Apart from the obvious blocking?

Why is that a problem?  You either wait until there's enough entropy, or you decide to go ahead and be insecure. The default configuration, since most users are not knowledgeable, should be to wait.

Why is that a problem? You either wait until there's enough entropy,...

The real problem is not that your process needs to wait longer, it's that it slows down all other processes, too, which do the same. Just assume that libcrypto would seed from /dev/random by default. Then all processes using OpenSSL would seed from /dev/random and draining the entropy pool. In the case of a web server, which forks for incoming connections, I guess you would notice the slow down a lot.
You can simulate this draining effect using dd. Just open one terminal running
watch -n 1 cat /proc/sys/kernel/random/entropy_avail

and several terminals running
dd if=/dev/random bs=1 count=32768 | hexdump

You will notice that the performance gets worse and worse if you add more and more of these.
Finally, compare it to the performance of reading from /dev/urandom:
dd if=/dev/urandom bs=1 count=32768 | hexdump

And again I ask, what is the alternative?  Competition for a scarce resource, in a land of naive programmers.

Just wait until the initial seeding has completed and then simply use it's output without blocking any further (that's what getrandom() does).
In this context you might find the following blog post interesting:
https://www.2uo.de/myths-about-urandom
The author's opinion might not be authoritative, but he seems to be supported by D. J. Bernstein's himself. And if I understand Pauli's comment correctly, even the FIPS lab members agree.

Yes, but and that is only after the getentropy syscall which should have been used,
but maybe the fallback after the mis-configuration is wrong, and should use /dev/random
even if it waits.

It would be good to have more detailed information about the VxWorks randlib in general and the randBytes() call in particular, before answering this question. Is there any official documentation available online or offline?

According to https://github.com/openssl/openssl/pull/8023#discussion_r256318746
You may assume that randBytes is returning error when not enough entropy, and when you read from
the randBytes the pool starts to get empty again, it depends on the hardware how long
this takes, can be seconds or minutes.
Is it better to wait or to fail if this happens?

use /dev/random even if it waits.

MAYBE we should only read 1 byte from there and after that continue with /dev/urandom.
I observe that once one byte is available several (~8) one byte reads succeed immediately
untit the /dev/random starts to block again.  As a compromise ?

Guys, some of you seem a bit confused about what getentropy() and getrandom() are and how they relate.

getrandom() is a syscall
getentropy() is a library routine that uses getrandom(), you can see it for yourself in the source

FIPS says that using the OS provided entropy is fine, it does not talk about which interface you talk to the OS.

FIPS 140-2 Implementation Guidance 7.15 Entropy Assessment makes a clear distinction:

In case of the /dev/urandom request, the call to this OS entropy generator is non-blocking. The data obtained from the non-blocking call is not guaranteed to possess the desired amount of entropy. How can the vendor provide the assurance that the requirements of the FIPS 140-2 AS.07.13 assertion are satisfied?
To meet these requirements, the vendor must first demonstrate that the initial call (that is, the first call after the module has been powered up or instantiated) to /dev/urandom returns the claimed amount of entropy.

There is quite a bit more wordage around this but it is the non-blocking nature before initial seeding that is pointed to as the problem.

MAYBE we should only read 1 byte from there and after that continue with /dev/urandom.
I observe that once one byte is available several (~8) one byte reads succeed immediately
untit the /dev/random starts to block again.

I'm pretty sure that this won't guarantee that /dev/urandom has been properly seeded.
NIST doesn't say anything about getrandom() yet.  However, after discussions with our FIPS lab, it appears that it would be a justifiable source and it is guaranteed to be seeded properly.

@paulidale

I'd put /dev/hwrng before /dev/prandom. /dev/prandom is a pseudo random generator like /dev/urandom and I don't believe claims about made about it being properly seeded.

I agree about /dev/prandom, and would actually remove it, it is seeded from /dev/urandom and
uses triple-DES, it only exists because of the hardware support, which might offer some speed-up.
However the /dev/hwrng is not limited to s390, any hardware device can register to be a TRNG device.
I guess if it is available it will be the seed /dev/random and /dev/urandom, so I would keep it
after /dev/urandom.

/dev/srandom should be before /dev/urandom and perhaps even before /dev/random. It is a good source.

I don't know anything about srandom, is this a BSD thing?  Is it similar to /dev/hwrng, the seed
of /dev/urandom ?

getentropy() is a library routine that uses getrandom(), you can see it for yourself in the source

I think you meant to provide a link to getentropy.c, not getrandom.c, but thanks for the link. Indeed, I was not aware that getentropy() is implemented in glibc only, based on the getrandom system call.
(But note that the two links above also show that you are you are just almost right: both functions are library routines:  while getrandom() is a thin wrapper around the getrandom system call, getentropy() adds more logic. ;-)  )

I'm pretty sure that this won't guarantee that /dev/urandom has been properly seeded.

At least with recent linux kernel that is the case.
The getrandom syscall unblocks exactly at the same time where /dev/random is able
to reading the first byte after system boot.

I'm pretty sure that this won't guarantee that /dev/urandom has been properly seeded.

At least with recent linux kernel that is the case.
The getrandom syscall unblocks exactly at the same time where /dev/random is able
to reading the first byte after system boot.

Theodore Ts'o explains in the commit message of commit c6e9d6f388947986 that the behaviour of /dev/urandom was not changed  to block initially (like getrandom) for compatibility reasons:
   This is because changing /dev/urandom reads to block represents an
   interface change that could potentially break userspace which is not
   acceptable.

Idea:
instead of actually reading 1 byte from /dev/random,
we could select /dev/random for readable, and once it is readable, read /dev/urandom.
That would work more or less around the issues with concurrent access.

A promising idea, indeed. I'd be interested to learn whether this trick helps to get rid of the "uninitialized urandom read" warning.

If you use getentropy() or getrandom(), the interface actually
blocks until the it has been initialized, on all OSs. It starts to
return data the same time /dev/random starts to return data the
first time.
If you use /dev/urandom on Linux, it reads wether it's initialized
or not. If you read /dev/random on Linux, it blocks until it's
initialiazed, and then says you remove entropy once you read
anything, which doesn't make sense with the current PRNG in the
kernel (it might have with the old one). Both /dev/random and
/dev/urandom on Linux really are broken. And they don't fix
/dev/urandom because it caused a hang in some applications (which
now hang anyway because they switched to getrandom()).
If you can't use getrandom()/getentropy(), you can work around
/dev/urandom's broken behaviour by reading 1 byte from
/dev/random. This 1 byte only needs to be read by 1 application
during the boot process, not every application should be doing
that. Linux distro's could fix this by adding that 1 byte read
somewhere in the boot sequence, but none do because the boot would
hang. We could do this in OpenSSL, or for FIPS we could just
document that it's up to the OS to make sure this has been done.
This is the only problem FIPS has with the use of /dev/urandom,
just like everybody else.
Recent Linux kernels actually are able to initialize the RNG within
a few seconds of booting.
On some other OSs, /dev/random and /dev/urandom are actually sane,
there is no difference between them, and only return data after
it's been initialized.
In short, just switch to getrandom()/getentropy().

Sure, this is just a fallback, when that is not available, but from the emotional reaction
on my proposal to move /dev/random before /dev/urandom, I concluded that there
must be a real problem somewhere.
Anyway, select for readable ought to guarantee that at least one byte can be
read without blocking.

Hmm, this does not really work as expected, (using v4.14-stable with RT branch):
the select waits a few seconds, and then the  /dev/urandom is still complaining
also reading 1 byte with dd is not waiting long enough,
acutally /dev/random seems to be returning bytes before it is supposed to be initialized:
root@socfpga_cyclone5:~# dd if=/dev/random bs=1 count=1 | hexdump -C ; dd if=/dev/urandom bs=1 count=1 | hexdump -C
1+0 records in
1+0 records out
00000000  f7                                                |.|
00000001
random: dd: uninitialized urandom read (1 bytes read)
1+0 records in
1+0 records out
00000000  96                                                |.|
00000001
root@socfpga_cyclone5:~# dd if=/dev/random bs=1 count=1 | hexdump -C ; dd if=/dev/urandom bs=1 count=1 | hexdump -C
1+0 records in
1+0 records out
00000000  76                                                |v|
00000001
random: dd: uninitialized urandom read (1 bytes read)
1+0 records in
1+0 records out
00000000  a3                                                |.|
00000001
root@socfpga_cyclone5:~# dd if=/dev/random bs=1 count=1 | hexdump -C ; dd if=/dev/urandom bs=1 count=1 | hexdump -C
1+0 records in
1+0 records out
00000000  d2                                                |.|
00000001
random: dd: uninitialized urandom read (1 bytes read)
1+0 records in
1+0 records out
00000000  5b                                                |[|
00000001
root@socfpga_cyclone5:~#

I don't know anything about srandom, is this a BSD thing?

Yes, it is a BSD device.  From the man page:

Strong random data.  This device returns reliable random data.  If sufficient entropy is not currently available (i.e., the entropy pool quality starts to run low), the driver pauses while more of such data is collected.  The entropy pool data is converted into output data using MD5.

MD5 ?

That's what the man page I found said.  I wouldn't be surprised if the algorithm had been changed since.  I wouldn't consider MD5 as being broken as an entropy whitening function -- collisions are very remote from reversibility.  I'd still advocate moving to something more recent of course.

Do not ever use /dev/random ... that is unacceptable

@t8m please explain this?

Apart from the obvious blocking?

Yes, that is the main reason. And for the reason that always-blocking /dev/random fighting for entropy is a broken concept on multi-process multi-user system it is often also blocked by security mechanisms such as SELinux. Basically /dev/random could be accepted as a special choice for user but it should never be used by default in general purpose crypto library.

Hmm, this does not really work as expected, (using v4.14-stable with RT patch):
the select waits a few seconds, and then the /dev/urandom is still complaining
also reading 1 byte with dd is not waiting long enough,
acutally /dev/random seems to be returning bytes before it is supposed to be initialized:

Because the entropy gathered is directed to various pools and never re-used. Roughly said, first the CRNG (which feeds /dev/urandom and getrandom()) is half-initialized with 64 bits of entropy (or so), then the entropy gathered goes to initialize the /dev/random entropy pool and only after that one is initialized, it goes to complete the CRNG initialization. It might not be exactly like that and it changed a little over various kernel versions but you can get the picture.
Basically: Please leave it on the OS to ensure /dev/urandom is properly initialized, do not try to outsmart it in the library code. It would have to be patched out anyway for general use in Linux OSes.

The idea is to wait on /dev/random using select(), but to never
actually read from it.
I'm sure opening /dev/random will fail in some cases, and we
should then just continue like we did previously.

If my understanding of the process is current, this will have a race condition, whereby something else could consume the collection pool's entropy before it is sent to urandom pool. Still, it is a better approach than doing nothing.

authors: bernd-edlinger kroeckx levitte mspncp paulidale richsalz t8m


text:
Move TLS CBC code into the providers

libssl has always managed its own CBC padding. Consequently there is constant time CBC padding removal code in libssl. This is also closely related to constant time code to remove the MAC from a MAC-then-encrypt record.
This PR moves the CBC padding and MAC removal code into the providers. This is important for the FIPS provider so that this code is moved inside the FIPS boundary.
Unfortunately it is not (yet) possible to completely excise this code from libssl still it is still required there in order to support legacy ENGINEs.

travis NIT is relevant.

All comments above addressed - as well as (hopefully) the travis nit. Please take another look.

travis error is relevant.

Fixups pushed to address latest feedback, and to resolve the Travis failure. Please take another look.

This pull request is ready to merge

Pushed. Thanks.

authors: mattcaswell openssl-machine slontis


text:
Fix up bad libcrypto.num

Fix up bad merge

This is urgent right?

I'm marking this urgent

Merging it

You happy for me to merge this now richard?

Merged
0608afe0963fc8188f0df1093e0eb42c32cd0a47 Fix up bad libcrypto.num

authors: jon-oracle levitte slontis


text:
Add some missing ciphers in 'enc' document

The original issue is #7273 and this commit fixes part of that issue.

Checklist

[x] documentation is added or updated

I guess this should affect 1.1.1 as well.

Pushed to master (41a6fa7) and 1.1.1 (ea94f19), closing...


text:
Make EVP_MD_CTX_ctrl() work for legacy use cases.

This is still required by engines and digestsign/digestverify

Checklist

[ ] documentation is added or updated
[ ] tests are added or updated

Strongly support.

ping @mattcaswell

Duplicate of #

Travis shows faults in some of the external project tests...  They should be subject for another PR.

Travis shows faults in some of the external project tests... They should be subject for another PR.

yes this PR is related to getting rid of the SSL3 issues in the extended tests.

(if anyone wonders how approval works in a case like this, where code from a different PR, #9126 in this case, gets incorporated here, it's really quite simple.  By incorporating #9126, @slontis has implicitly approved it, which is sufficient for that code, and since I'm approving of this PR, that covers the rest of this PR as usual)

Travis failure is not relevant.

authors: asicminer001 beldmit levitte mattcaswell slontis


text:
Added option to view failed builds in TestNG graph.

Allows boolean option to show failed builds in test graph
for TestNg plugin.(Default: False)

Thank you for contributing to openstack-infra/jenkins-job-builder!
openstack-infra/jenkins-job-builder uses Gerrit for code review.
Please visit
http://docs.openstack.org/infra/manual/developers.html#development-workflow
and follow the instructions there to upload your change to Gerrit.

authors: magnida openstack-gerrit

repo: openstack-infra/jenkins-job-builder


text:
Check for cifmw_repo_setup_component_name definition

DLRN promote jobs in integration lines are failing this check as cifmw_repo_setup_component_name
is not defined. Add a check for the var definition before checking length.
As a pull request owner and reviewers, I checked that:

[ x] Appropriate testing is done and actually running
[x ] Appropriate documentation exists and/or is up-to-date:

[x ] README in the role
[ x] Content of the docs/source is reflecting the changes

recheck

testing here: https://review.rdoproject.org/r/c/testproject/+/53185

recheck


text:
[httpd] Set X-Forwarded-Proto only if empty

As done for neutron-operator [1], adding a conditional to set the header only if it is empty.
This is required in case we deploy with tls.podlevel=false and tls.ingress=true.
Jira: https://issues.redhat.com/browse/OSPRH-12376
[1] https://github.com/openstack-k8s-operators/neutron-operator/pull/453

/cherry-pick 18.0-fr1


text:
Add amenity=prep_school preset

Tutorial schools/cram schools.
https://wiki.openstreetmap.org/wiki/Tag%3Aamenity%3Dprep_school

It looks like someone just added this page a few days ago.
Could they maybe use a different tag?  "prep school" has a very different meaning than this, at least in US English.

repo: openstreetmap/iD

license: ISC


text:
add preset to landuse=aquaculture

https://wiki.openstreetmap.org/wiki/Tag:landuse%3Daquaculture

Thanks @willemarcel!
I also styled these blue like other watery things and added the "Produce" field.

Great! Thank you!

authors: bhousel willemarcel


text:
fix: :bug: Fix multiple appending debug vintage unknown label

Fix multiple appending on debug vintage unknown label.
Fixes: #9457

Thanks for the suggestion. I changed the fix, so that the t.append method is still used. The simpler .text(t(…)) solution had the downside that the meta attributes about the language of the displayed strings is not rendered in the final html.

authors: furkanmutlu-tomtom tyrasd


text:
Support tunnel=culvert

Currently there is no direct support for adding tunnel=culvert to a waterway. iD contains a hack to convert tunnel=yes to tunnel=culvert when the object contains a waterway=* tag, but it would preferable for this to be built into the structure_waterway field itself.

I'm not sure if this was changed since this issue was opened, but one can set the tunnel type also for waterways in the "structure" field:

Do you think something should be changed here?

authors: bryceco tyrasd

repo: openstreetmap/id-tagging-schema


text:
check details.response.statusCode when error is falsy

Description
If response status is 200, minimal-request returns null as error. In order to have explicit feedback that a resource that should be forbidden is exposed instead, we need to check against the details.response.statusCode.
Before

After

Thanks!

authors: matteofigus mattiaerre

repo: opentable/oc-registry-test


text:
DX improved logging

Use slog.XXXContext() everywhere there is a context
Use slog.Handler to log values in the context like request ID
Formalize logging message format - lowercase, only period punctionation.
Decide on and record Error codes
Create logging integration test to enforce the above

notes:

Don't lose error, have an error stack trace, keep chain intact
No fat. or log. statements.
slog with errors.join

everytime you create an error, slog it, with some golang line or code block identifier
ideally everything in one line log
slog.XXXWithContext
add service to Context so log messages show which service

Include user error message, not just technical  -- error id, user message
Follow Java

Users:
library users - error messaging through API and SDK
end users messaging

possible option to log line number and package

reference: https://betterstack.com/community/guides/logging/logging-in-go/

@strantalis @pflynn-virtru We're going to do this, we just need to flesh this ticket out a bit more.

Could we also get something added to Github Discussions or the README about our logging practice to better onboard teams?

authors: biscoe916 jrschumacher pflynn-virtru

repo: opentdf/platform


text:
otThreadGetDeviceRole returns OT_DEVICE_ROLE_CHILD long after the router has timed it out

Hi, my team has encountered a peculiar bug which is reproduced in non-standard way, so I expect some grain of salt when looking at it. There's a setup with NCP (border) router and few (2-4) devices, all of which are custom platform. Some devices are connected to a debugger and may be paused for indefinite amount of time. If the pause is long enough that the router times-out the device, it does not reconnect once resumed. Capturing the packets show that the device only sends data requests (and receives ACKs to them). Calling otThreadGetDeviceRole always return OT_DEVICE_ROLE_CHILD, instead of OT_DEVICE_ROLE_DETACHED.
Has anyone noticed similar behavior? Could it be enough that the ACKs to data requests are enough to keep the child from switching to detached state? I have not yet looked deep enough to determine what's the exact problem here, it may as well be platform or debug related, but any suggestions on where to look first in openthread stack are welcome.

Thank you, @jwhui! It completely answers my question.

repo: openthread/openthread


text:
fix: incorrect buttongroup data type #21

PR
PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our Commit Message Guidelines
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

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

What is the current behavior?

Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

fix #21

repo: opentiny/tiny-engine


text:
✨ [Feature]: Supports the global display of the loading progress bar of page loading, asynchronous request, and file upload

What problem does this feature solve
The loading progress bar of page loading, asynchronous request, and file upload is displayed globally.
What does the proposed API look like
please see https://www.iviewui.com/view-ui-plus/component/navigation/loading-bar

您好，感谢你的意见，我们内部评估下~~

你好，我们有提供全局弹窗和loading组件，您提的需求感觉有点偏业务了

authors: qianmoQ zzcr

repo: opentiny/tiny-vue


text:
🐛 [Bug]: 【Grid-右键菜单-单元格菜单】右键菜单无法移到二级菜单中

Version
latest
Vue Version
latest
Link to minimal reproduction
复现demo地址：https://opentiny.design/tiny-vue/zh-CN/os-theme/components/grid-context-menu#grid_Example-shortcutMenu-cell-menu
Step to reproduce

表格中右键弹出菜单
鼠标移到一级菜单中，没法再移入二级菜单

What is expected
No response
What is actually happening
No response
Any additional comments (optional)
No response

您好，感谢你的意见，我们内部评估下~~

已修复此问题，等待3.12.0版本发布

authors: kagol zzcr


text:
incorrect values in 1.6 Transformations tutorial

In the "In practice" section of the 1.6 Transformations tutorial - https://opentk.net/learn/chapter1/6-transformations.html#in-practice, the trans matrix in the first code box is incorrect.  Based on the text description, the x and y values should be 1.0f, not 0.1f, i.e. it should be this:
Matrix4 trans = Matrix4.CreateTranslation(1.0f, 1.0f, 0.0f);
however it is written as this:
Matrix4 trans = Matrix4.CreateTranslation(0.1f, 0.1f, 0.0f);

ignore, this was meant for the OpenTK website

repo: opentk/LearnOpenTK


text:
Questionable Shader class disposal advice/code

I had copied the Shader class without initially thinking about it much. Today I was basically rewriting it and noticed the disposal logic, much of which originated with the tutorial code. This is a bit nitpicky, but the discussion of unmanaged resource cleanup in the 1.2 Hello Triangle chapter at the end of the Compiling the Shaders section may warrant reconsideration.
.NET finalizers aren't remotely equivalent to C++ destructors, so it doesn't make sense to state, "We can't do it in the finalizer due to the Object-Oriented Language Problem." Nobody should be contemplating resource cleanup in the finalizer as correct behavior in the first place, completely irrespective of whether or not it's problematic for OpenGL specifically.
The code, of course, is meant to output a warning if disposal wasn't correctly called but (a) that's detrimental to performance because declaring a finalizer adds it to .NET's finalizer tracking queue, (b) there's no guarantee about when a finalizer might be invoked, or whether it will be invoked at all, ever, and (c) in practice they are never invoked when the application is exiting, which is the most likely scenario here. So in short, while a warning message looks like a good idea, in reality it'll never actually be seen. It's wasted effort.
I'd say it makes the most sense just to show a Dispose method. Also, I suppose the sample code was cut-and-pasted from somewhere else since arguments like bool disposing aren't even used (that's an arguably-bad design when you want to know whether or not Dispose is being called from the finalizer.) Even though the class shouldn't have a finalizer, it should still call SuppressFinalize in case a derived class does declare a finalizer.
Just keep it simple:
private bool IsDisposed = false;

public virtual void Dispose()
{
    if (IsDisposed) return;

    GL.DeleteProgram(Handle);
    IsDisposed = true;
    GC.SuppressFinalize(this);
}

Like I said, nitpicky.

Simply seal the class and remove the GC.XXX. There is virtually - no pun intended - no need to derive from Shader in the first place, but rather inject it or instantiate it in place

@deccer I disagree. For example, my user-facing app wraps the shader class from my library to provide additional context, like the key value used by an LRU caching scheme. DI isn't practical in my case since the program is almost constantly loading arbitrary combinations of shader programs and libraries.
Sealing would be a pretty drastic design decision just to avoid issuing SuppressFinalize. Technically if you're really opposed to the GC command for some reason, omitting it wouldn't really hurt anything, and doesn't change the points I made: the docs shouldn't mention finalizers and the sample code isn't handling disposal properly.

@MV10
I agree that quoting the "Object Oriented Problem" is misleading here (we should be talking about the fact that finalizers run on their own thread and can't call gl because of that). But the shader class implementation is actually fine.
I will address the three main concerns.

(a) that's detrimental to performance because declaring a finalizer adds it to .NET's finalizer tracking queue

This is negligible and if you dispose the object properly it never gets added to the finalize queue anyway.

(b) there's no guarantee about when a finalizer might be invoked, or whether it will be invoked at all

This is not a problem as this is not meant to be a 100% bullet proof solution. It's mean to indicate and remind you that you might be leaking OpenGL objects during runtime.

(c) in practice they are never invoked when the application is exiting, which is the most likely scenario here.

This is by design. You should NOT be cleaning up OpenGL objects at program termination. The operating system and gpu driver are infinitely faster at nuking all of your allocated memory than you having to do it manually yourself. You are just making termination of your program needlessly slow.
The whole bool isDisposing business comes from the Microsoft official guidelines for implementing IDisposable.
When I have time I will revise this chapter of the tutorial and fix some of the issues and do a little cleanup.
Also a reminder that the tutorial code in no way aims to be "production ready" code. It's meant for learning and clarity, not for robust and scalable implementation. The tutorial code should be modified heavily if used as a base for a game project.

authors: MV10 NogginBops deccer


text:
add module version of rtcstats

adds a version of rtcstats which is exported as a module.
Most importantly this allows me to insert it after adapter.js
so that my Edge shim can be monitored.
Still haven't figured out a good way how to maintain both versions.

@fippo The tests have been failing for the longest time. I think you mentioned the old version of the adapter in the past. Do you have a way to fix it ?

I think this is close to the right way to do it. But we need a build process to generate rtcstats.js from this version.

updated. The only thing missing now is allowing a way to configure which getUserMedia objects to wrap.

so the same code that passed three days ago is now generating errors on travis... :-/

@aullman FYI looks like selenium-webdriver needs to be pinned to 3.3.0 as well (might be incompability between newer versions and the pinned geckodriver)
😕

squashing...

authors: fippo manasdpradhan

repo: opentok/rtcstats


text:
Use wildcard wildcard as a default operation name for server spans

Use wildcard path as a default operation name for server spans.
cc @bhs @yurishkuro

How come no tests need to change?

There already have been tests for both decorators. This PR just adds wildcard decorator to a default set of decorators. In test tracing feature is created with builder specifying a set of decorators.

in my experience people prefer as little customization as possible, relying on the default behavior. So backwards compatibility of the default behavior is important to have its own tests.

Agree, this is the main reason of this PR. I'm going to restructure tests in the next PR.

authors: pavolloffay yurishkuro

repo: opentracing-contrib/java-jaxrs


text:
🛑 [CN] OpenUPM API /packages/extra is down

In 8a83618, [CN] OpenUPM API /packages/extra (https://api.openupm.cn/packages/extra) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM API /packages/extra is back up in b4a8d60 after 7 minutes.

repo: openupm/upptime-openupmcn


text:
🛑 [Global] OpenUPM Registry /-/all is down

In 3f16c9c, [Global] OpenUPM Registry /-/all (https://package.openupm.com/-/all) was down:

HTTP code: 502
Response time: 258 ms

Resolved: [Global] OpenUPM Registry /-/all is back up in 9e5d49f after 19 minutes.

repo: openupm/upptime


text:
🛑 [CN] OpenUPM Website Packages is down

In d8a74c2, [CN] OpenUPM Website Packages (https://openupm.cn/packages/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Website Packages is back up in 3fe78ae.


text:
How can I render ellipse as visualization for polygon annotation

My actions before raising this issue

[ x] Read/searched the docs
[x ] Searched past issues

My team is using the annotations for drawing an ellipse around a desired object. Currently, we generate the polygon based (8-point) annotations and use a separate backend for generating the ellipses. Our intent is to use JS's openCV module to render an ellipse instead of the polygon when 8 points are available.
We have modified CVAT for our use case and we will be able to modify the source code for our use case. While I am exploring this, I wanted to get some pointers or help on the implementation direction. Could you please help in this regard?

@bsekachev , could you please advise?

@Iravindr,
Hi, I do not think you need OpenCV.js here.
SVG library we use (svg.js) supports ellipses. I believe the feature should be implemented exactly the same way as for boxes, polygons, etc.

Thank you Boris and Nikita. I will close the issue now. This should work for me.

authors: bsekachev lravindr nmanovic

repo: openvinotoolkit/cvat


text:
Support cloud storage

Motivation and context

Support work with remote cloud storage without copying data to CVAT
Related issue: #863
How to generate temporary credentials (S3) e.g.
import boto3
# generate temporatry credentials
sts_client = boto3.client('sts', aws_access_key_id="...", aws_secret_access_key="...")
tokens = sts_client.get_session_token()
aws_access_key_id = tokens.get('Credentials').get('AccessKeyId')
aws_secret_access_key = tokens.get('Credentials').get('SecretAccessKey')
aws_session_token = tokens.get('Credentials').get('SessionToken')

# test a credentials validity
s3 = boto3.client('s3',
	aws_access_key_id=aws_access_key_id,
	aws_secret_access_key=aws_secret_access_key,
	aws_session_token=aws_session_token
)
s3.list_buckets()

How has this been tested?

Manually with swagger
REST API

GET /api/v1/cloudstorage
POST /api/v1/cloudstorage
GET /api/v1/cloudstorage/{id}/?action=content
PATCH /api/v1/cloudstorage/{id}

Supported cloud providers:

[x] Azure Blob container
[x] AWS S3 bucket
[ ] Google Drive

Iterations:

Support images
Support video
Support archive

Checklist

[ ] I submit my changes into the develop branch
[ ] I have added description of my changes into CHANGELOG file
[ ] I have updated the documentation accordingly
[ ] I have added tests to cover my changes
[ ] I have linked related issues (read github docs)
[ ] I have increased versions of npm packages if it is necessary (cvat-canvas,
cvat-core, cvat-data and cvat-ui)

License

[ ] I submit my code changes under the same MIT License that covers the project.
Feel free to contact the maintainers if that's a concern.
[ ] I have updated the license header for each file (see an example below)

# Copyright (C) 2020 Intel Corporation
#
# SPDX-License-Identifier: MIT

Coverage decreased (-0.3%) to 62.393% when pulling 61398f87208bab3685e729528c3cd02403824ca0 on mk/support_cloud_storage into c126d2afeb30f1a255261b1b8be5ebd01b4455a9 on develop.

I'm really interested by this feature, do you have an idea of when it will be integrated?
By the way, I'm using MinIO; that is a S3-compatible storage, i imagine it should be used as for AWS S3 therefore?

I'm really interested by this feature, do you have an idea of when it will be integrated?

I will continue to develop this functionality in the near future.

@dvkruchinin, Could you please help me and take a look at CI / E2E_testing (actions_tasks2)? It was failed for some reason..

@dvkruchinin, Could you please help me and take a look at CI / E2E_testing (actions_tasks2)? It was failed for some reason..

Sure. I'll see what's going on.

@Marishka17 , could you please add documentation how to add cloud storages? There are some problems with error messages. They provide zero information from my perspective.
{
  "provider_type": "AWS_S3_BUCKET",
  "resource": "nmanovic-data",
  "display_name": "mydata",
  "credentials_type": "TEMP_KEY_SECRET_KEY_TOKEN_SET",
  "session_token": "ZZZZZZZZZZ",
  "account_name": "test",
  "key": "XXXXXXXXXXXXXXXXXXX",
  "secret_key": "YYYYYYYYYYYYYYYYYYYY",
  "specific_attributes": "",
  "description": "test"
}

The request works, but
{
  "provider_type": "AWS_S3_BUCKET",
  "resource": "nmanovic-data",
  "display_name": "mydata1",
  "credentials_type": "TEMP_KEY_SECRET_KEY_TOKEN_SET",
  "session_token": "ZZZZZZZZZZ",
  "account_name": "test",
  "key": "XXXXXXXXXXXXXXXXXXX",
  "secret_key": "YYYYYYYYYYYYYYYYYYYY",
  "specific_attributes": "string",
  "description": "test"
}

Produce list index out of rang
{
  "provider_type": "AWS_S3_BUCKET",
  "resource": "nmanovic-data",
  "display_name": "mydata1",
  "credentials_type": "TEMP_KEY_SECRET_KEY_TOKEN_SET",
  "session_token": "ZZZZZZZZZZ",
  "account_name": "test",
  "key": "XXXXXXXXXXXXXXXXXXX",
  "secret_key": "YYYYYYYYYYYYYYYYYYYY",
  "specific_attributes": "",
  "description": ""
}

The request produces:
{
  "description": [
    {
      "message": "This field may not be blank.",
      "code": "blank"
    }
  ]
}

If I try to run http://localhost:8080/api/v1/cloudstorages/1/content without any extra arguments, it gives me list index out of range.  Probably it isn't enough to understand that the user didn't provide the manifest file.
Also I believe that a manifest file should be specified when we create a cloud storage. What do you think? I don't think that it is the right idea to specify it when you want to list content of the attached cloud drive.

@Marishka17 , get_specific_attributes function works incorrectly.  ''.split('&') returns ['']. It has len 1.

@Marishka17 , could you please add documentation how to add cloud storages? There are some problems with error messages. They provide zero information from my perspective.

In order to create S3 storage need to indicate:

for access with credentials

{
  "provider_type": "AWS_S3_BUCKET",
  "resource": "nmanovic-data",
  "display_name": "mydata1",
  "credentials_type": "TEMP_KEY_SECRET_KEY_TOKEN_SET",
  "session_token": "ZZZZZZZZZZ",
  "key": "XXXXXXXXXXXXXXXXXXX",
  "secret_key": "YYYYYYYYYYYYYYYYYYYY",
  "specific_attributes": "",
  "description": ""
}

for access without credentials

{
  "provider_type": "AWS_S3_BUCKET",
  "resource": "nmanovic-data",
  "display_name": "mydata1",
  "credentials_type": "ANONYMOUS_ACCESS",
  "specific_attributes": "",
  "description": ""
}

{
  "provider_type": "AWS_S3_BUCKET",
  "resource": "nmanovic-data",
  "display_name": "mydata",
  "credentials_type": "TEMP_KEY_SECRET_KEY_TOKEN_SET",
  "session_token": "ZZZZZZZZZZ",
  "account_name": "test",
  "key": "XXXXXXXXXXXXXXXXXXX",
  "secret_key": "YYYYYYYYYYYYYYYYYYYY",
  "specific_attributes": "",
  "description": "test"
}

The request works, but
{
  "provider_type": "AWS_S3_BUCKET",
  "resource": "nmanovic-data",
  "display_name": "mydata1",
  "credentials_type": "TEMP_KEY_SECRET_KEY_TOKEN_SET",
  "session_token": "ZZZZZZZZZZ",
  "account_name": "test",
  "key": "XXXXXXXXXXXXXXXXXXX",
  "secret_key": "YYYYYYYYYYYYYYYYYYYY",
  "specific_attributes": "string",
  "description": "test"
}

Produce `list index out of range

specific_attributes should contain structure like key1=value1&key2=value2.
In real case e.g "specific_attributes": "range=eu-west-2"
Ok, I will add validator.

If I try to run http://localhost:8080/api/v1/cloudstorages/1/content without any extra arguments, it gives me list index out of range. Probably it isn't enough to understand that the user didn't provide the manifest file.

I checked this case and my request is fulfilled, the content is returned.

Also I believe that a manifest file should be specified when we create a cloud storage. What do you think? I don't think that it is the right idea to specify it when you want to list content of the attached cloud drive.

I believe that it is wrong to specify manifest path when creating a storage, because in the provided implementation it will not be possible to create many identical storeges. It is assumed that the customer has a valid S3 bucket and connects it. Customer can have several datasets in the bucket and he can simply specify the desired manifest instead of creating the same storage with different manifest locations.
When creating a task, when expansion a specific existing cloud storage, a request GET cloudstorage/{id}/content will be sent and we will get storage content mapped with the content of the manifest (by default, it will be assumed that the manifest is at the root, but it will be possible to specify the location of the manifest and update the tree of available files.)

{
  "description": [
    {
      "message": "This field may not be blank.",
      "code": "blank"
    }
  ]
}

@nmanovic , is that better?
{
  "provider_type": "",
  "resource": "",
  "display_name": "existing_display_name",
  "credentials_type": "",
  "specific_attributes": "",
  "description": ""
}

{
  "provider_type": "AWS_S3_BUCKET",
  "resource": "XXX",
  "display_name": "",
  "credentials_type": "ANONYMOUS_ACCESS",
  "specific_attributes": "",
  "description": ""
}

If I try to run http://localhost:8080/api/v1/cloudstorages/1/content without any extra arguments, it gives me list index out of range. Probably it isn't enough to understand that the user didn't provide the manifest file.

I checked this case and my request is fulfilled, the content is returned.

Also I believe that a manifest file should be specified when we create a cloud storage. What do you think? I don't think that it is the right idea to specify it when you want to list content of the attached cloud drive.

I believe that it is wrong to specify manifest path when creating a storage, because in the provided implementation it will not be possible to create many identical storeges. It is assumed that the customer has a valid S3 bucket and connects it. Customer can have several datasets in the bucket and he can simply specify the desired manifest instead of creating the same storage with different manifest locations.
When creating a task, when expansion a specific existing cloud storage, a request GET cloudstorage/{id}/content will be sent and we will get storage content mapped with the content of the manifest (by default, it will be assumed that the manifest is at the root, but it will be possible to specify the location of the manifest and update the tree of available files.)

@Marishka17 , let's discuss how it is going to look like for users. There are multiple ways to implement the feature. If you can provide good UX in UI, I'm totally fine with any approach. In my proposed approach we can clone a connection and change something (e.g. manifest file) during the cloning process. Thus you can name the connection Cityscapes and it will correspond to one Cityscapes dataset.

{
  "description": [
    {
      "message": "This field may not be blank.",
      "code": "blank"
    }
  ]
}

@nmanovic , is that better?
{
  "provider_type": "",
  "resource": "",
  "display_name": "existing_display_name",
  "credentials_type": "",
  "specific_attributes": "",
  "description": ""
}

{
  "provider_type": "AWS_S3_BUCKET",
  "resource": "XXX",
  "display_name": "",
  "credentials_type": "ANONYMOUS_ACCESS",
  "specific_attributes": "",
  "description": ""
}

It is much better.

specific_attributes should contain structure like key1=value1&key2=value2.
In real case e.g "specific_attributes": "range=eu-west-2"

@Marishka17 could you please add a note about that into swagger docs?

New PR without multiple dummy changes from pretifier: https://github.com/openvinotoolkit/cvat/pull/3326

authors: Marishka17 azhavoro coveralls dvkruchinin iraadit nmanovic


text:
Update ARM Compute to v22.05

Fixed build for macOS with M1

please changed release from 22.05 to 22.08

please changed release from 22.05 to 22.08

@allnes ARM Compute was updated

authors: allnes ilyachur


text:
[Notebook Hello Segmentation] segmented image result is not displaying expected image

Describe the bug
The expected image is not being displayed.
Expected behavior

*Output

.take

@sarang-26 could you share:

which OS are you using?
your hardware (CPU and GPU)
did the issue happen on both CPU & GPU?
OpenVINO version

Closing issue, feel free to re-open or start a new issue if additional assistance is needed.


text:
Code commit for release 2022_1_1

Code commit for release 2022_1_1.

OpenVINO™ Security Add-on 2022.1.1.


text:
Chart - Number of courses enrolled per day

add chart for Number of courses enrolled per day

https://github.com/openvitae-tech/blackboard-lms/pull/354

repo: openvitae-tech/blackboard-lms


text:
Use instance in VC Playground

The VC Playground is a demonstration application for Verifiable Credential issuance and verification: https://vcplayground.org.
Wallets interact with a VC API instance in order to accomplish the exchanges, issuance and verification.
The VC Playground maintainers have offered to integrate this VC API implementation in the past. A challenge has previously been the use of additional LD Contexts. However, this issue may be resolved by the use of Credo for credential operations (#20).

VC Playground has SVG credential rendering features: https://lists.w3.org/Archives/Public/public-credentials/2024Aug/0005.html

repo: openwallet-foundation-labs/vc-api


text:
[CLI] "package refresh" seems not work?

Environment details:
Irrelevant
Steps to reproduce the issue:

Execute "wsk package refresh NAMESPACE"

Provide the expected results and outputs:
There should be messages regarding successful package refreshing.

Provide the actual results and outputs:
Error message is returned:
Request failure: Malformed request, did you specify a bluemix namespace?

Additional information you deem important:

It seems a backend REST API issue. I checked the HTTP transaction, the request should be fine. There is namespace in the URL path.

REQUEST:
[POST]	https://openwhisk.ng.bluemix.net/api/v1/namespaces/XX_YY/packages/refresh
Req Headers
{
  "Authorization": [
    "Basic XXXXXXX"
  ]
}RESPONSE:Got response with code 400
Response body size is 67 bytes
Response body received:
{"error":"Malformed request, did you specify a bluemix namespace?"}

Hi @archerzz, thanks for raising this issue.
Do you have a second _ in either your Organization and/or Space name? If so, duplicate of #91 .

Sorry for the delay. Yes. There are multiple "_". Please close is as duplicated. Thanks.

authors: archerzz markusthoemmes

repo: openwhisk/openwhisk


text:
[model] Allow indoor location without indoor coords #54

Fixed the issue by adding a confirmation script to the
loci.js which gives the opportunity to the admin to
confirm if he/she wish to save the indoor location
without indoor coords. Also modified the admin to make
sure this is saved without validation errors.
I also modified the model of object_location to allow
indoors to be None when type is indoor and no floorplan
is provided.
Fixes #54

Coverage decreased (-0.0005%) to 99.775% when pulling 214057439a70cb971d699e845a6ccbc101a0bd91 on NoumbissiValere:allow_indoor into 7dd2a48a940c1f8eaf14cfe03c49fe7ef41fe0a4 on openwisp:master.

@nemesisdesign Please can you review this?
Thanks

Ok thanks for reviewing. I will review the work and make these points are met

Happy this work finally got in :smile:

authors: NoumbissiValere coveralls

repo: openwisp/django-loci


text:
i18n: luci-app-smartdns: add template

Signed-off-by: Franco Castillo castillofrancodamian@gmail.com

Thanks merged

authors: castillofrancodamian feckert

repo: openwrt/luci


text:
Comparing HTTP headers in a case-insensitive fashion

Span context propagation fails when HTTP header names are converted to lowercase (e.g. when using spring-boot).
E.g.

Header sent from client: X-B3-TraceId
Header obtained from http request object in spring-boot: x-b3-traceid

From RFC 2616 - "Hypertext Transfer Protocol -- HTTP/1.1"
"Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive"
So, extractor logic should be able to extract context information even if http headers were in different case. Unfortunately, it's not the case, TextMapView::get fails to get header values.
Fix: Updated extractor getter logic (TextMapView) to perform case insensitive lookups in HTTP headers data.

I've added a unit test. After some profiling I decided to push a third commit (I refactored a bit my code for performance reasons, just to avoid converting propagation keys to lower case anytime we instantiate a TextMapView).

Hi guys, Is this fix is release ready ? If so when can we expect release ?

just cut 0.18.2

authors: adriancole carlossnt pawel-kowalski

repo: openzipkin/brave-opentracing


text:
Ensures http responses served from cache don't end up marked remote

Thanks to @amccarthy-atlas for the easy to follow solution
Fixes #864

while we dont have anything standard for this, the same concern exists in okhttp. probably recording a cache.hit tag or similar could reduce confusion. @shakuzen @devinsba @anuraaga any thoughts?

while we dont have anything standard for this, the same concern exists in okhttp. probably recording a cache.hit tag or similar could reduce confusion

I wonder if it would it be worthwhile to distinguish between HTTP cache hit and some other kind of cache hit? http.cache.hit?

as our namespaces are currently flat within a classifier, I'd mildly
suggest http.cache_hit
On Wed, Feb 6, 2019 at 2:35 AM Tommy Ludwig notifications@github.com
wrote:

while we dont have anything standard for this, the same concern exists in
okhttp. probably recording a cache.hit tag or similar could reduce confusion
I wonder if it would it be worthwhile to distinguish between HTTP cache
hit and some other kind of cache hit? http.cache.hit?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/openzipkin/brave/pull/865#issuecomment-460871412, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAD616fiiDqyQ2Ve8hGT1CoBC_J1n8Vqks5vKjFogaJpZM4ai0wp
.

as I think the tag name is somewhat bikeshed.. I'll merge and someone can pipe in, in the next day or two, if they care to have something besides http.cache_hit :P

authors: adriancole shakuzen

repo: openzipkin/brave


text:
The issue about Kafka 0.10+ Collector Auto-configure Module???

[root@blninst06 zipkin]# KAFKA_BOOTSTRAP_SERVERS=10.122.23.134:9092 \

java \
-Dloader.path='kafka10.jar,kafka10.jar!/lib' \
-Dspring.profiles.active=kafka \
-cp zipkin.jar \
org.springframework.boot.loader.PropertiesLauncher

Error: Could not find or load main class org.springframework.boot.loader.PropertiesLauncher

Note: we just upgraded to Spring Boot 2.0.1 I've verified that kafka
still works using our docker setup with version 2.8.1
You can look at how it works just in case:
https://github.com/openzipkin/docker-zipkin/blob/master/zipkin/Dockerfile#L35

I just manually tested too https://github.com/openzipkin/zipkin/tree/master/zipkin-autoconfigure/collector-kafka10#quick-start
feel free to get support here if you need it https://gitter.im/openzipkin/zipkin

repo: openzipkin/zipkin


text:
Removes unused canned scripts and tar.gz publication

We shouldn't be storing things not used, or complicating publication
with duplicate artifacts.
The scripts stored in zipkin's repo are not used at Twitter, not used by
the dist routine, not used by our bin directory, and not used in docker.
At the moment, the tar.gz dist isn't used by anything either. When our
artifact publication works, there's nothing in the tar.gz we can do that
we can't do with the fat jar. Once we have versioned fat jars, we should
change docker to use them.. we don't need a tar.gz IOTW.

cc @rtyler @eirslett @kristofa @jamescway

:+1:

Having the versioned and published fat jars will be great!
:+1:

+1

Thanks for the quick look, folks!

authors: adriancole eirslett jamescway kristofa