profile
viewpoint
Arzhan "kai" Kinzhalin busykai @clearlinux Santa Clara, CA USA https://clearlinux.org/

clearlinux/clear-linux-documentation 88

This repository contains the documentation source files for Clear Linux OS.

busykai/brackets-indent-right 7

Brackets extension to detect and set the indentation according to the indentation used in the current file.

busykai/ua-chrome-extension 2

User-Agent string switcher (Chrome extension + socket.io-based aux server).

busykai/ws-rpc 2

WebSocket-based browser-to-browser RPC

busykai/brackets-xlint 1

Report compatibility issues of your HTML5 application.

busykai/acrn-hypervisor 0

Project ACRN hypervisor

busykai/afterstep 0

Super configurable, extra lightweight, and fluidly fast Window Manager for X

busykai/autospec 0

RPM packaging automation tool

busykai/brackets 0

An open source code editor for the web, written in JavaScript, HTML and CSS.

busykai/brackets-jshint 0

Adds JSHint support to Brackets

MemberEvent

fork busykai/afterstep

Super configurable, extra lightweight, and fluidly fast Window Manager for X

http://www.afterstep.org

fork in 13 days

startedoneapi-src/oneAPI-spec

started time in 17 days

issue closedclearlinux/distribution

Proper transition from `systemd-networkd` to `NetworkManager` needed

In #289, @busykai mentioned the transition from systemd-networkd to NetworkManager, more details are available in man stateless.

To finish the switching, the user needs to execute the following

sudo systemctl disable systemd-networkd
sudo systemctl stop systemd-networkd
sudo rm /etc/NetworkManager/conf.d/systemd-networkd-unmanaged.conf
sudo systemctl restart NetworkManager

Well, this is fine. But it turns out that I have to do this after every reboot, or many gnome components won't work properly, including gnome-weather not finding my location and gnome-software warning of no internet connection.

I'm wondering what is bringing the deleted systemd-networkd back?

closed time in 18 days

lebensterben

issue commentclearlinux/distribution

Proper transition from `systemd-networkd` to `NetworkManager` needed

thanks, @lebensterben. i will close it as i have not seen other reports, suspecting corrupt local state, especially since you tweaked /var/lib/swupd.

lebensterben

comment created time in 18 days

issue commentclearlinux/distribution

Proper transition from `systemd-networkd` to `NetworkManager` needed

hey @lebensterben. thanks for the report. it did not happen on my system... at first glance, non of the previous troublemakers sneaked back in. could you take a look at the last time migration state was created?

sudo ls -l /var/lib/swupd/one-shot-updates

If it's new[ish] could you also look at when /var/lib/swupd was modified (and files within it).

I think it's about time we remove the migration script in the first place. We gave enough time to upgrade for everybody.

lebensterben

comment created time in 20 days

push eventbusykai/uefi-simple

Arzhan Kinzhalin

commit sha 22d1d4c3be2bbacf901d0c8f452375cea8cd5e3a

Bogus install rule.

view details

push time in 2 months

push eventbusykai/uefi-simple

Arzhan Kinzhalin

commit sha db912f9dea3f64867c9bc6487244a28e60bb517e

Add bogus COPYING. THIS IS NOT A LICENSE.

view details

push time in 2 months

fork busykai/uefi-simple

A simple 64bit UEFI application of Hello World! without using any UEFI toolkit.

fork in 2 months

created tagclearlinux/clrtrust

tagv0.1.3

Clear Linux TLS Trust Store Management

created time in 2 months

release clearlinux/clrtrust

v0.1.3

released time in 2 months

push eventclearlinux/clrtrust

puneetse

commit sha 34ba387c1cc8d1c804e708202e8eda905b20a19e

Add manpage Add a manpage for clrtrust and Makefile entries for building from markdown

view details

puneetse

commit sha d6b67111a403c3aaf35e9101a3f515c54f2fa212

Update README.md Simplify README to highlight Clear Linux OS implementation and link to the manpage for usage information.

view details

puneetse

commit sha f24e620d7ec83cff997e22ae45d9ba9614465593

Update .gitignore Ignore files that are not markdown files in man directory.

view details

push time in 2 months

PR merged clearlinux/clrtrust

Add manpage

This PR:

  • adds a manpage for clrtrust
  • adds Makefile entries for building from markdown.
  • simplifies README to link to manpage for usage information
+201 -104

21 comments

4 changed files

puneetse

pr closed time in 2 months

pull request commentclearlinux/clrtrust

Add manpage

Looks good, @puneetse! Awesome change and thanks for doing this. Merging now.

puneetse

comment created time in 2 months

Pull request review commentclearlinux/clrtrust

Add manpage

 CFLAGS := -W -Wall -Werror -std=gnu9x  BINDIR := /usr/bin LIBEXECDIR := /usr/libexec+MANDIR := /usr/share/man -.PHONY: build install check clean+.PHONY: build install check clean docs  build: clrtrust-helper clrtrust

I'm sorry if I confused you. It was either not using ronn or remove it from the default target, but not both. The reason for this is simple: we need to run this build in mock environment for package and should be able to build it.

A really proper way to define build target would actually be along these lines:

build: clrtrust-helper clrtrust man/clrtrust.1

man/%.1: man/%.1.md
       pandoc -s -f markdown -t man $< --output $@

clean:
       rm -rf clrtrust-helper clrtrust-helper.o clrtrust man/clrtrust.1

And no need to have docs as a phony target.

Additionally, the .gitignore needs to be modified to ignore all the files in man/ directory, except for .md files:

man/
!man/*.md

Does it make sense?

puneetse

comment created time in 2 months

pull request commentclearlinux/clrtrust

Add manpage

I cannot install the gem. And I need to have it if I want to contribute to my own project. :)

puneetse

comment created time in 2 months

pull request commentclearlinux/clrtrust

Add manpage

Also, I'm seeing this. Not sure if I'm the only one, but I would like to avoid dealing with this to just build the thing:

--> sudo gem install ronn
Building native extensions. This could take a while...
ERROR:  Error installing ronn:
	ERROR: Failed to build gem native extension.

    current directory: /usr/lib64/ruby/gems/2.6.0/gems/rdiscount-2.2.0.1/ext
/usr/bin/ruby -I /usr/lib64/ruby/2.6.0 -r ./siteconf20200401-977754-bf1hno.rb extconf.rb
mkmf.rb can't find header files for ruby at /usr/lib64/ruby/include/ruby.h

You might have to install separate package for the ruby development
environment, ruby-dev or ruby-devel for example.

extconf failed, exit code 1

Gem files will remain installed in /usr/lib64/ruby/gems/2.6.0/gems/rdiscount-2.2.0.1 for inspection.
Results logged to /usr/lib64/ruby/gems/2.6.0/extensions/x86_64-linux/2.6.0/rdiscount-2.2.0.1/gem_make.out
puneetse

comment created time in 2 months

pull request commentclearlinux/clrtrust

Add manpage

it's a phony target.

puneetse

comment created time in 2 months

pull request commentclearlinux/clrtrust

Add manpage

They will already be created - therefore there is no need to run it.

This is a maintenance issue going forward: since docs cannot be part of the default target, it needs to be run separately. I really encourage to look into something Clear supports. This PR needs to be changed either way.

puneetse

comment created time in 2 months

pull request commentclearlinux/clrtrust

Add manpage

I think we either need to a) switch to pandoc as per @phmccarty's suggestion or b) remove docs from the default target. I prefer a) since it makes it clean on Clear. b) is prone to docs-less updates (even though I don't expect the tool to change much anyways).

puneetse

comment created time in 2 months

pull request commentclearlinux/clrtrust

Add manpage

gem install ronn

from mock?

puneetse

comment created time in 2 months

pull request commentclearlinux/clrtrust

Add manpage

@puneetse, also, I cannot find ronn among Clear Linux packages. It does not seem like we have it. It will not build. Were you using another distro to build this?

puneetse

comment created time in 2 months

Pull request review commentclearlinux/clrtrust

Add manpage

+## SYNOPSIS++**clrtrust** is a tool for generating and managing a centralized trusted+certificate store.++`clrtrust [-v|--verbose] [-h|--help] [-c|--internal-rehash] <command> [options]`++## DESCRIPTION++A trust store contains a set of X.509 certificates which the operating system+and applications should consider trustworthy. ++The `clrtrust` tool provides a frontend for centralized trust store management.+It allows for adding (trusting) and removing (distrusting) certificate+authorities (CAs). It also provides maintenance commands for viewing and+re-generating the trust store.++Certificates can be provided by the operating system for out-of-box+functionality. Certificates can also be provided and modified by privileged+users.++It is up to each application to make use of the trust store generated by+`clrtrust`.++## OPTIONS++```+Usage: clrtrust [-v|--verbose] [-h|--help] [-c|--internal-rehash] <command> [options]++    -v | --verbose          Shows more details about execution+    -c | --internal-rehash  Forces use of internal implementation of c_rehash+    -h | --help             Prints this message++    Commands+        generate    generates the trust store+        list        list CAs+        add         add trust to a CA+        remove      remove trust to a CA+        restore     restore trust to previously removed CA+        check       sanity/consistency check of the trust store++clrtrust <command> --help to get help on specific command.+```++**Commands that modify the trust store require root privileges.**++- `clrtrust generate [-f|--force]`++  The `generate` command has no arguments and generates a unified trust store+  composed of system-provided and user-provided certificates, if any. The+  optional `--force` parameter will forcibly generate the trust store, even if+  it results in an empty store. See the FILES section for paths used for trust+  store generation.+++- `clrtrust list`++  The `list` command has no arguments and outputs a list of trusted certificates+  with the following fields:++  `id` uniquely identifies the certificate. It can be used as input to other+  `clrtrust` commands such as  `remove` or `restore`.++  `File`  contains the file path of the certificate in the trust store. ++  `Authority` shows the name of the organization that issued the certificate.+    This field is extracted from the certificate file.++  `Expires` shows the expiration date of the certificate. This field is+    extracted from the certificate file.++++- `clrtust add [<certificateFile|Id> ...] [-f|--force]` 

One cannot add certificate by id, since it's not known yet to clrtrust, only a file is acceptable at this point.

puneetse

comment created time in 2 months

Pull request review commentclearlinux/clrtrust

Add manpage

+## SYNOPSIS++**clrtrust** is a tool for generating and managing a centralized trusted+certificate store.++`clrtrust [-v|--verbose] [-h|--help] [-c|--internal-rehash] <command> [options]`++## DESCRIPTION++A trust store contains a set of X.509 certificates which the operating system+and applications should consider trustworthy. ++The `clrtrust` tool provides a frontend for centralized trust store management.+It allows for adding (trusting) and removing (distrusting) certificate+authorities (CAs). It also provides maintenance commands for viewing and+re-generating the trust store.++Certificates can be provided by the operating system for out-of-box+functionality. Certificates can also be provided and modified by privileged+users.++It is up to each application to make use of the trust store generated by+`clrtrust`.++## OPTIONS++```+Usage: clrtrust [-v|--verbose] [-h|--help] [-c|--internal-rehash] <command> [options]++    -v | --verbose          Shows more details about execution+    -c | --internal-rehash  Forces use of internal implementation of c_rehash+    -h | --help             Prints this message++    Commands+        generate    generates the trust store+        list        list CAs+        add         add trust to a CA+        remove      remove trust to a CA+        restore     restore trust to previously removed CA+        check       sanity/consistency check of the trust store++clrtrust <command> --help to get help on specific command.+```++**Commands that modify the trust store require root privileges.**++- `clrtrust generate [-f|--force]`++  The `generate` command has no arguments and generates a unified trust store+  composed of system-provided and user-provided certificates, if any. The+  optional `--force` parameter will forcibly generate the trust store, even if+  it results in an empty store. See the FILES section for paths used for trust+  store generation.+++- `clrtrust list`++  The `list` command has no arguments and outputs a list of trusted certificates+  with the following fields:++  `id` uniquely identifies the certificate. It can be used as input to other+  `clrtrust` commands such as  `remove` or `restore`.++  `File`  contains the file path of the certificate in the trust store. ++  `Authority` shows the name of the organization that issued the certificate.+    This field is extracted from the certificate file.++  `Expires` shows the expiration date of the certificate. This field is+    extracted from the certificate file.++++- `clrtust add [<certificateFile|Id> ...] [-f|--force]` ++  The `add` command takes one or more certificates as required argument(s). The+  certificate is identified by a file path or `Id`. The certificate file(s)+  must be PEM-encoded with only one certificate per file. The optional+  `--force` parameter will forcibly add the certificate to the trust store,+  even if it is not a root CA. ++  Adding a root CA to the trust store allows applications using the trust store+  to trust the root CA certificate, trust certificate chains issued by the+  authority, verify the authenticity of peer's certificate, and establish a+  connection.+  +++- `clrtrust remove [<certificateFile|Id> ...]`++  The `remove` command takes one or more certificates as required argument(s).+  The certificate is identified by a file path or `Id`. The argument can be an+  `id` of the certificate (see the `list` command) or the file path of the

Nit: id and Id are used interchangeably. Specially since i uppercase is easily confused with l lowercase, I'd rather prefer using id (lowercase) throughout.

puneetse

comment created time in 2 months

Pull request review commentclearlinux/clrtrust

Add manpage

+## SYNOPSIS++**clrtrust** is a tool for generating and managing a centralized trusted+certificate store.++`clrtrust [-v|--verbose] [-h|--help] [-c|--internal-rehash] <command> [options]`++## DESCRIPTION++A trust store contains a set of X.509 certificates which the operating system+and applications should consider trustworthy. ++The `clrtrust` tool provides a frontend for centralized trust store management.+It allows for adding (trusting) and removing (distrusting) certificate+authorities (CAs). It also provides maintenance commands for viewing and+re-generating the trust store.++Certificates can be provided by the operating system for out-of-box+functionality. Certificates can also be provided and modified by privileged+users.++It is up to each application to make use of the trust store generated by+`clrtrust`.++## OPTIONS++```+Usage: clrtrust [-v|--verbose] [-h|--help] [-c|--internal-rehash] <command> [options]++    -v | --verbose          Shows more details about execution+    -c | --internal-rehash  Forces use of internal implementation of c_rehash+    -h | --help             Prints this message++    Commands+        generate    generates the trust store+        list        list CAs+        add         add trust to a CA+        remove      remove trust to a CA+        restore     restore trust to previously removed CA+        check       sanity/consistency check of the trust store++clrtrust <command> --help to get help on specific command.+```++**Commands that modify the trust store require root privileges.**++- `clrtrust generate [-f|--force]`++  The `generate` command has no arguments and generates a unified trust store+  composed of system-provided and user-provided certificates, if any. The+  optional `--force` parameter will forcibly generate the trust store, even if+  it results in an empty store. See the FILES section for paths used for trust+  store generation.+++- `clrtrust list`++  The `list` command has no arguments and outputs a list of trusted certificates+  with the following fields:++  `id` uniquely identifies the certificate. It can be used as input to other+  `clrtrust` commands such as  `remove` or `restore`.++  `File`  contains the file path of the certificate in the trust store. ++  `Authority` shows the name of the organization that issued the certificate.+    This field is extracted from the certificate file.++  `Expires` shows the expiration date of the certificate. This field is+    extracted from the certificate file.++++- `clrtust add [<certificateFile|Id> ...] [-f|--force]` ++  The `add` command takes one or more certificates as required argument(s). The+  certificate is identified by a file path or `Id`. The certificate file(s)+  must be PEM-encoded with only one certificate per file. The optional+  `--force` parameter will forcibly add the certificate to the trust store,+  even if it is not a root CA. ++  Adding a root CA to the trust store allows applications using the trust store+  to trust the root CA certificate, trust certificate chains issued by the+  authority, verify the authenticity of peer's certificate, and establish a+  connection.+  +++- `clrtrust remove [<certificateFile|Id> ...]`++  The `remove` command takes one or more certificates as required argument(s).+  The certificate is identified by a file path or `Id`. The argument can be an+  `id` of the certificate (see the `list` command) or the file path of the+  certificate.++  Removing a root CA from the trust store distrusts the certificate for+  applications using the trust store. Certificate chains issued by the+  authority will no longer be trusted, authenticity of the peer's certificate+  will no longer be verified, and a connection will not be established.++++- `clrtrust check`++  The `check` command has no arguments and validate the consistency of a+  previously generated unified trust store.+++## EXAMPLES++### View the list of trusted CAs++`clrtrust list`++The command above outputs a list of trusted certificates in the format below:++  ```+  id: FA:B7:EE:36:97:26:62:FB:2D:B0:2A:F6:BF:03:FD:E8:7C:4B:2F:9B+  File: /var/cache/ca-certs/anchors/certSIGN_ROOT_CA.crt+  Authority: /C=RO/O=certSIGN/OU=certSIGN ROOT CA+  Expires: Jul  4 17:20:04 2031 GMT+  ```++The certificate can be further inspected using the `openssl x509` command. For+example:++  ```+  openssl x509 -in /var/cache/ca-certs/anchors/certSIGN_ROOT_CA.crt -noout -text+  ```++### Add (trust) a root CA++`clrtrust add ~/PrivateCA.pem`++The command above will add a root CA certificate located in the+`~/PrivateCA.pem` file. If the certificate file is not in the PEM format, use+`openssl x509` command to convert to PEM first. For example:++  ```+  openssl x509 -in PrivateCA.cer -inform der -out PrivateCA.pem -outform pem+  ```++### Remove (distrust) a root CA++`clrtrust remove ~/PrivateCA.pem`++The command above will remove a root CA certificate located in the+`~/PrivateCA.pem` file from the trust store and distrust it.+++## FILES++*/var/cache/ca-certs*++  Generated directory of certificates and verification keys. Do not modify+  contents outside of `clrtrust`.++*/usr/share/ca-certs/*++  Operating-system provided certificates and keys. Do not modify contents+  outside of `clrtrust`.++*/etc/ca-certs*

Nit: please add slash at the end to indicate these are directories, as in case of /usr/share/...

puneetse

comment created time in 2 months

more