statcan / shiny Goto Github PK

I'm assuming we don't want this running as root, if that can be avoided?

CC @zachomedia , I think this image mounts and Azure file share, does mounting that force us to use root or anything? (If so, can we get around this by maybe having an init-container with root which mounts the file-share and copies into a volume? Or something?)

I updated the image but noticed that the shiny deployment doesn't switch to the new image. Even when I manually restarted the deployment it didn't switch (still using the old sha).

How would I do this manually (until such a time as we integrate it into the CD) ?

What if we created a second branch that pushed to a development version of the shiny server, this would let me create a more autonomous testing system. I'd be able to merge into a dev branch, port-forward to test the server out and confirm that everything works, then I can send a PR to master afterwards. How does that sound?

This issue is to revert the changes applied in #14.

#14 applied a temporary hack to allow shiny dashboards to download files from cansim. This adjusted TLS settings to use an older version as required by the STC/cansim site.

A real fix to this issue requires changes by STC/cansim - this has been requested by @zachomedia . When the upstream issue is resolved, we can revert changes from #14

When creating a PR to update packages in shiny for PR 26 StatCan/R-dashboards#26 the container scan showed the following vulnerabilities:

• CVE-2019-20367
• CVE-2020-25696
• CVE-2020-25696
• CVE-2019-18814
• CVE-2020-15180

Scanning for vulnerabilties...

║ VULNERABILITY ID │ PACKAGE NAME │ SEVERITY │ DESCRIPTION

║ CVE-2019-20367 │ libbsd0 │ CRITICAL │ nlist.c in libbsd before 0.10.0 has an out-of-bounds read
║ │ │ │ during a comparison for a symbol name from the string table
║ │ │ │ (strtab).

║ CVE-2020-25696 │ libpq-dev │ CRITICAL │ A flaw was found in the psql interactive terminal of
║ │ │ │ PostgreSQL in versions before 13.1, before 12.5, before
║ │ │ │ 11.10, before 10.15, before 9.6.20 and before 9.5.24. If an
║ │ │ │ interactive psql session uses \gset when querying a
║ │ │ │ compromised server, the attacker can execute arbitrary code
║ │ │ │ as the operating system account running psql. The highest
║ │ │ │ threat from this vulnerability is to data confidentiality
║ │ │ │ and integrity as well as system availability.

║ CVE-2020-25696 │ libpq5 │ CRITICAL │ A flaw was found in the psql interactive terminal of
║ │ │ │ PostgreSQL in versions before 13.1, before 12.5, before
║ │ │ │ 11.10, before 10.15, before 9.6.20 and before 9.5.24. If an
║ │ │ │ interactive psql session uses \gset when querying a
║ │ │ │ compromised server, the attacker can execute arbitrary code
║ │ │ │ as the operating system account running psql. The highest
║ │ │ │ threat from this vulnerability is to data confidentiality
║ │ │ │ and integrity as well as system availability.

║ CVE-2019-18814 │ linux-libc-dev │ CRITICAL │ An issue was discovered in the Linux kernel through 5.3.9.
║ │ │ │ There is a use-after-free when aa_label_parse() fails in
║ │ │ │ aa_audit_rule_init() in security/apparmor/audit.c.
║ CVE-2020-15180 │ mariadb-common │ CRITICAL │ No description is available for this CVE.

Our shiny report under visualize-team/example2 uses two packages that aren't installed on the shiny server.

Can you add them to your packages file?

sqldf
shinythemes

Thanks!

I think there was an update over the weekend in the STC website that allows only TLSv1.2 and not TLSv1.3.

This is an issue in some of the latest linux OSs (Debian, Ubuntu 20.04 LTS) when downloading a CODR table from R with thelibrary(cansim) (or file.download()). The cansim R library is used in the EV shiny application.

Some potential solutions are to modify the openssl.cnf or to allow both versions of TLS.

@ca-scribner @blairdrummond

Need a good Pachyderm-based workflow for ingressing data into R-Shiny.

Required by AVA shiny (StatCan/aaw#363)
Replace default demo page with custom one or redirect

A few people asking how to keep their datasources up-to-date in their dashboards. This is a development question not a platform question, but we can still provide a tiny bit of guidance in the docs. I recommended that someone use this:

https://shiny.rstudio.com/reference/shiny/latest/invalidateLater.html

The refresh logic is built into the app this way, rather than with a cronjob or something crazy. Then I think we can recommend that they pull from an API or from their shared MinIO storage.

Question for @justbert; can the Shiny server access Minio? Do we need to create a faux-user with read-only access to the shared buckets?

CC @ca-scribner