hiera-eyaml fails to start
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
hiera-eyaml (Ubuntu) |
Fix Released
|
Critical
|
Unassigned | ||
Jammy |
Fix Released
|
Critical
|
Patrik Lundin |
Bug Description
Ever since upgrading to jammy eyaml fails completely. I thought it was related to gpgme, ruby-gpg or my GPG keys. But then I tried in a lxc container and it obviously doesn't work at all.
This also goes for both my laptop and my workstation after upgrading to jammy. I used to use eyaml everyday in both hirsute and focal.
root@u1:~# eyaml edit foo.eyaml
/usr/share/
from /usr/share/
from /usr/share/
from /usr/share/
from /usr/share/
from /usr/share/
from /usr/bin/
from /usr/bin/
root@u1:~# history
1 apt-get update
2 apt-get install hiera-eyaml
3 eyaml edit foo.eyaml
4 history
root@u1:~#
ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: hiera-eyaml 3.2.2-2
ProcVersionSign
Uname: Linux 5.15.0-30-generic x86_64
ApportVersion: 2.20.11-0ubuntu82
Architecture: amd64
CasperMD5CheckR
Date: Wed May 18 15:59:02 2022
PackageArchitec
ProcEnviron:
TERM=xterm-
PATH=(custom, no user)
LANG=C.UTF-8
SourcePackage: hiera-eyaml
UpgradeStatus: No upgrade log present (probably fresh install)
===
SRU-formatted update (added by Patrik Lundin)
[ Impact ]
The eyaml command is unusable as it stands, running it will lead to a backtrace.
[ Test Plan ]
Running `eyaml` will result in a backtrace:
```
$ eyaml
/usr/share/
from /usr/share/
from /usr/share/
from /usr/share/
from /usr/share/
from /usr/share/
from /usr/bin/
from /usr/bin/
```
After installing the patched package it starts working again:
```
$ sudo dpkg -i hiera-eyaml_
$ eyaml
Unknown subcommand
Usage: eyaml <subcommand>
Please use one of the following subcommands or help for more help:
createkeys, decrypt, edit, encrypt, recrypt, version
```
At this point the edit command reported in the original report above works
again:
```
$ eyaml createkeys
[hiera-eyaml-core] Created key directory: ./keys
[hiera-eyaml-core] Keys created OK
$ eyaml edit foo.eyaml
```
Enter some example content in the editor:
```
# | This is eyaml edit mode. This text (lines starting with # | at the top of
# | the file) will be removed when you save and exit.
# | - To edit encrypted values, change the content of the DEC(<num>
# | block.
# | WARNING: DO NOT change the number in the parentheses.
# | - To add a new encrypted value copy and paste a new block from the
# | appropriate example below. Note that:
# | * the text to encrypt goes in the square brackets
# | * ensure you include the exclamation mark when you copy and paste
# | * you must not include a number when adding a new block
# | e.g. DEC::PKCS7[]!
---
foo: DEC::PKCS7[bar]!
```
On save it returns:
```
[hiera-eyaml-core] foo.eyaml doesn't exist, editing new file
```
The file now contains an encrypted value:
```
$ cat foo.eyaml
---
foo: ENC[PKCS7,
```
Re-running "eyaml edit foo.eyaml" will show the contents unencrypted again.
[ Where problems could occur ]
The patch basically makes sure the returned spec is of the correct type and
changes it if necessary. I guess it could break if ruby objects stopped
supporting the ".respond_to?" method, but it seems unlikely since it is part of
the "default root of all Ruby objects" as defined in
https:/
Status changed to 'Confirmed' because the bug affects multiple users.