tridentli / trident Goto Github PK

It appears that some wiki tables don't render correctly in the main view, but render fine in the preview.

When trying to give a user sysadmin rights:
$ tcli user get sysadmin trident
no
$ tcli user set sysadmin trident true
Updated sysadmin
$ tcli user get sysadmin trident
no
$ tcli user set sysadmin trident yes
Updated sysadmin
$ tcli user get sysadmin trident
no

When trying to take away a user's sysadmin rights:
$ tcli user set sysadmin trident no
Value for sysadmin was already the requested value
$ tcli user set sysadmin trident false
Value for sysadmin was already the requested value

The help says:
$ tcli user set help
Help for user set
...
sysadmin <username> <sysadmin> System Administrator - Wether the user is a System Administrator

(Note: "Wether" should be "Whether".)

What does <sysadmin> mean? Is the tcli command expecting a boolean? A username?

The old portal would pre-set the user to the group they have access to without asking them to select if they had only one. The current portal requires a selection, that's a bug.

Ability to tick a 'send update notification' email to group when an update is made to the WIKI or a new file is uploaded to Files.... including a hyperlink to the relevant Wiki page or file.

https://talks.golang.org/2014/names.slide#6

oops...

trident$ grep 'func ._.' src/lib/.go | wc -l
32
trident$ grep 'func ..' src/ui/.go | wc -l
17
pitchfork$ grep 'func .*.' lib/.go | wc -l
342
pitchfork$ grep 'func ._.' ui/*.go | wc -l
149

and of course those will all have to be chased up and fixed in all other callers :(
I'm happy to take a stab at this, once I sort out how to actually test/compile the lot of this.

In /group/{group}/main/member/{member}/ if you look at the 'Vouches by
' the Affiliation for all the Vouchees is user's affiliation.

"Vouches by" shows affiliation, but "Vouches for" does not, update that too.

This is a test issue in the dev kanboard.

We need a test.trident.li from which we can automatically run the Silenium tests instead of relying on one person doing that locally.

We should likely change this to list the affiliation of the vouchee, it would make more sense in a long list of vouches.

I think the Release ZIP files which contain the packages don't currently include ext-src packages, based on the last download I did today; did CI / automated creation of this ZIP skip it?

panic: no supported languages found []string{"en-US"}

goroutine 1 [running]:
panic(0x982da0, 0xc820280470)
/opt/go-1.6.1/src/runtime/panic.go:464 +0x3e6
trident.li/pitchfork/lib.NewPfCtx(0xc68da8, 0xc68da0, 0xc68db0, 0x0, 0x0, 0x0, 0x0)
/opt/dims/src/trident/ext/_gopath/src/trident.li/pitchfork/lib/ctx.go:222 +0x10b
trident.li/trident/src/lib.NewTriCtx(0x0, 0x0)
/opt/dims/src/trident/ext/_gopath/src/trident.li/trident/src/lib/ctx.go:13 +0x5d
trident.li/pitchfork/cmd/setup.Setup(0xb40318, 0x6, 0xb402b8, 0x7, 0xb39710, 0x7, 0xc66f00, 0x5, 0xbd3900, 0x21, ...)
/opt/dims/src/trident/ext/_gopath/src/trident.li/pitchfork/cmd/setup/setup.go:171 +0xa8c
main.main()
/opt/dims/src/trident/src/cmd/tsetup/tsetup.go:22 +0xf5

With Pitchfork having a reasonable amount of documentation, I should be applying that to Trident too.

When browsing the web portal as a SysAdmin user, and going to the "User" page to list all users, the "Forward" button to advance the offset by 10 to see the "next page" of users does nothing.

The system passes the argument of offset=10 to the system, but the page does not advance to the next page of users.

See attached output.
trident-logout-error.txt

We need an email sent every 24 hours, summarising the new nominations in a trust group.

The email should be per trust group and also be controllable as a trust group setting.

user merge <user_to_destroy> <user_to_merge_into> - Merge

For the emails we sent out, make sure there is no (valid) HTML in them.

While we do not set the content to HTML, likely quite a few mail clients will just render it as HTML.

Thus at minimum we should never allow '<' and '>' in any fields that we render as email, so that no HTML tags can be formed.

See amongst others:

http://lcamtuf.coredump.cx/postxss/
https://thehackerblog.com/keeping-positive-obtaining-arbitrary-wildcard-ssl-certificates-from-comodo-via-dangling-markup-injection/index.html

When creating a new mail list within a group - a PGP key gets generated for it and a new email address generated.

However - when that PGP key is downloaded and imported to GPG Keychain - the Email address field is blank when 'key details' are selected.

(NB: It is still possible to send emails encrypted to the address that is generated and they get correctly forwarded - but finding the correct key becomes a manual process)

[email protected]:~$ tcli user get ident kevinthomsen1585
kevinthomsen1585

really? I would never have guessed that the userid i put in is the userid of the user :(

I really want to know: "for user X what is their relevant data in the system?" I guess I can do that by asking for each in turn:
image Image - Upload an image of yourself, the system will scale it
ident User Name - The username of this user
descr Full Name - Full Name of this user
name_first First Name - The First Name of the user
name_last Last Name - The Last name of the user
affiliation Affiliation - Who the user is affiliated to
post_info Postal Details - Postal address or other such details
sms_info SMS - The phone number where to contact the user using SMS messages
im_info I.M. - Instant Messaging details
tz_info Timezone - Timezone details
tel_info Telephone - The phone number where to contact the user using voice messages
airport Airport - Closest airport for this user
bio_info Biography - Biography for this user
sysadmin System Administrator - Wether the user is a System Administrator
login_attempts Number of failed Login Attempts - How many failed login attempts have been registered
no_email Email Disabled - Email address is disabled due to SMTP errors
hide_email Hide email address - Hide my domain name when forwarding group emails, helpful for DMARC and SPF
recover_email Email Recovery address - The password used for recovering passwords
furlough Furlough - Extended holiday or furlough
entered Entered - Timestamp in UTC
activity Last Activity - Timestamp in UTC

(also, 'username' here means really 'ident', right? or it seems that way)

but that seems ... less helpful. This also doesn't tell me the user's associated email addresses, though I can find that in:
$ tcli user list username

I can set a user's email per group with:
$ tcli user email member set

which seems cumbersome for 'change all delivery'... is there a way to do all delivery without a shell loop?

Indeed, lets make it:

tcli system backup <backup.tar.gz> []
tcli system restore <backup.gz> []
and then have:

tcli tg backup [overwrite=yes|no]
tcli tg restore [overwrite=yes|no]
Which are the CLI variants that take a local file (and thus PERM_SYS_ADMIN only).
But the UI would bypass the CLI outputting a file "download" for backup while accepting a file through the UI for input (ala the way that the files module works).

The problem with "restore" is though if one is going to overwrite things or merge them and handling conflict resolution in change usernames etc.

This is all for 'next' though.

Many portals will just want to have a "Login" page, with a link to an optional About page for not-logged in people.

This allows people who have access to login easily (instead of having to click on the login button) and people who do not have an account to see some details about the portal.

Thus change that / == login and (toggleable) /about/ can show what is currently on /.

Enable Markdown rendering for /about/ while we are at it.

Create a package that collects all gopath deps into one installable package so that sbuild will work without requiring network access.

At the moment we're using "user email confirm_force" which requires a sysadmin.
Move this step to into pf/lib/user.go Create() as part of the insert, remove from "trident/src/ui/vouch.go"

When forcing 2FA on a system wide basis new users (who have not yet enabled 2FA) are not able to log on to the system.

When turning on this global setting would it be possible to send every user (who has not yet enabled 2FA) a one-time code to enter into the 2FA window to enable them to log in and set up this feature. (They will obviously already know their password - so I suggest there would be no loss of security sending this in the clear to users who have not yet enabled their PGP)

When in the wiki, if you click on the current page in the crumb-bar you get the current URL + a "/" bringing you to an empty page.

Group admins should have a place where they can see pending nominations and manipulate them if needed.

In addition if we need to allow users to have similar visibility as we used to.

We have a DB table for publishing of upcoming events and outages. Sysadmin needs a page to populate it and The notices need to be displayed to users on login and require an ACK

Verify that one can re-nominate somebody who has previously failed nominations.

This should especially be possible for admins; not so for groupmembers as the failed status is likely for a reason (timeout, but possibly rejected...)

(Bug, using version Trident 1.4.5):

1. I have had reports from users that when they change their passwords they get an error message saying "Sending email failed"

2. In Administrator mode I get a similar message when using the CLI to try and reset the password - and no dual email for password resets get sent.

3. However If I try to force change passwords to the portal I get the following error message returned from the CLI: "An error occured: Sending email failed" [Note typo in error message]

However: Experimentation indicates that whilst the same error message is generated in all 3 scenarios, the new password is ACTUALLY applied in 1. and 3. - whilst not 2.

Jan 23 18:07:45 portal.usa3.ops-trust.net tridentd[32762]: 2017/01/23 18:07:45 Error: Menu: No user,hidden permission for MenuPath(user): Not authenticated
Jan 23 18:07:45 portal.usa3.ops-trust.net tridentd[32762]: 2017/01/23 18:07:45 Error: NoAccess: Not Logged in
Jan 23 18:07:45 portal.usa3.ops-trust.net tridentd[32762]: 2017/01/23 18:07:45 Error: Translation missing trident.li/pitchfork/ui.login >>>Username<<<
Jan 23 18:07:45 portal.usa3.ops-trust.net tridentd[32762]: 2017/01/23 18:07:45 Error: Translation missing trident.li/pitchfork/ui.login >>>Your username<<<
Jan 23 18:07:45 portal.usa3.ops-trust.net tridentd[32762]: 2017/01/23 18:07:45 Error: Translation missing trident.li/pitchfork/ui.login >>>[email protected]<<<
Jan 23 18:07:45 portal.usa3.ops-trust.net tridentd[32762]: 2017/01/23 18:07:45 Error: Translation missing trident.li/pitchfork/ui.login >>>Password<<<
Jan 23 18:07:45 portal.usa3.ops-trust.net tridentd[32762]: 2017/01/23 18:07:45 Error: Translation missing trident.li/pitchfork/ui.login >>>Your password<<<
Jan 23 18:07:45 portal.usa3.ops-trust.net tridentd[32762]: 2017/01/23 18:07:45 Error: Translation missing trident.li/pitchfork/ui.login >>>4.very/difficult_p4ssw0rd<<<
Jan 23 18:07:45 portal.usa3.ops-trust.net tridentd[32762]: 2017/01/23 18:07:45 Error: Translation missing trident.li/pitchfork/ui.login >>>Two Factor Code<<<
Jan 23 18:07:45 portal.usa3.ops-trust.net tridentd[32762]: 2017/01/23 18:07:45 Error: Translation missing trident.li/pitchfork/ui.login >>>Two Factor Token (if configured)<<<
Jan 23 18:07:45 portal.usa3.ops-trust.net tridentd[32762]: 2017/01/23 18:07:45 Error: Translation missing trident.li/pitchfork/ui.login >>>314159<<<
Jan 23 18:07:45 portal.usa3.ops-trust.net tridentd[32762]: 2017/01/23 18:07:45 Error: Translation missing trident.li/pitchfork/ui.login >>>Comeback<<<
Jan 23 18:07:45 portal.usa3.ops-trust.net tridentd[32762]: 2017/01/23 18:07:45 Error: Translation missing trident.li/pitchfork/ui.login >>>Required<<<
Jan 23 18:07:45 portal.usa3.ops-trust.net tridentd[32762]: 2017/01/23 18:07:45 Error: Translation missing trident.li/pitchfork/ui.login >>>Cookies<<<
Jan 23 18:07:45 portal.usa3.ops-trust.net tridentd[32762]: 2017/01/23 18:07:45 Error: Translation missing trident.li/pitchfork/ui.login >>>Sign In<<<
Jan 23 18:07:45 portal.usa3.ops-trust.net tridentd[32762]: 2017/01/23 18:07:45 Error: Translation missing trident.li/pitchfork/ui.login >>>Message<<<
Jan 23 18:07:45 portal.usa3.ops-trust.net tridentd[32762]: 2017/01/23 18:07:45 Error: Translation missing trident.li/pitchfork/ui.login >>>Error<<<

I'm unclear as to whether or not these are important, probably no one cares and the logs shouldn't be made... or someone should scrape these out and 'do something' code-wise, yes?

In previous incarnations an admin (sysadmin) could reset a user's passwd either:

1. directly (set passwd to foo)
2. reset the user's passwd to nil && wait for automated/random passwd generation and nominator contact

Note that knowing the user's identify in the portal was limited to: "wikiname" not "email address" previously, this seems to have changed in the trident system to "email address" maybe.

These seem fine, or they worked well enough.
In today's trident deployment the process, as I read it is:

1. be an admin of a TG (or sysadmin)
   2a) poke through the webui and reset each user in turn to a random passwd emailed to the nominator
   2b) poke through the webui to the 'cli' in the webui ... (or use the cli on a portal host directly) to:
   login (*)
   admin yourself (swapadmin)
   user password reset username nominator
   In some cases the nominator doesn't have gpg, so I'm unclear where the passwd would be sent... if at all?
   I'd like to be able to reset the passwd to a known-text, and tell the nominator what that text is?

This looks interesting:
batch Run a batch script (sysadmin level username/password required for non-sysadmin logged in users)

but there aren't any docs on it's usage? What's the sane way to reset ~12 users at a time? :)

*: Why do I pass my userid, passwd and token on the command line? the data is then in logs and available to anyone who's watching 'ps' output, right? that seems extra uncool.

Jan 4 21:44:52 portal.usa3.ops-trust.net tridentd[3421]: 2017/01/04 21:44:52 Error: HandleCmd() - err: Could not select user

New notification fail if emails contain upper case characters

Each time I try to enter an email address that contains an upper case character I get the following error message: "Could not verify email address" - but it appears to work if I delete the 'half created' userID (using the CLI) then retry with the nominated email address all in lower case.

Is it possible to automatically convert all characters to lower case in the email submission box prior to having to enter all the remaining details only for things to fail - or deploy some other mechanism to avoid unnecessary fails.

in /system/settings:

I suggest adding the following explanatory text on roll-over help popups

CLI Enabled : “Show the Web Command Line Interface to Regular users. Default: Off (Always available for Administrators).”


API Enabled : add “Default: On”


OAuth/OpenID Enabled : add “Default: On”


No Web Indexing : add “Default: On”


Require 2FA : add “If set to “off” individual users can still choose to as option. Default Off”

https://people.debian.org/~stapelberg/debconf13-making-your-package-work-with-systemd.pdf

Display thumbnails at bigger size in lists, and even bigger in profile and list.

Hello.

There is a formatting issue on some subpages. So far, I've replicated these issues on the 2FA Tokens page for a given token, and the user email editing page. These make the GUI look a little weird, because input boxes expand beyond the edges of the tables.

Screenshots attached, while erasing some data from them with black lines.

2FA Token Edit page:

Email edit page for a specific email:

need a matching configuration option for target_outvouch, to support groups wanting to increase the number of required out-vouches for an active transition without impacting existing members.

I'm trying to set the 'descr' attribute of mailing lists, and I get this output when trying to use both 'tcli ml set help' and 'tcli ml get help':
$ tcli ml set help
--> Request Failed: Get http://localhost:8333/api/ml/set/help: EOF
$ tcli ml get help
--> Request Failed: Get http://localhost:8333/api/ml/set/help: EOF

I tried just guess the syntax, and it looks like it works:
$ tcli ml set descr main demo 'Demo and Fun'
Updated descr
$ tcli ml get descr main demo
Demo and Fun
$ tcli ml list main
admin TG Administration
demo Demo and Fun
general General Discussion
vetting Vetting and Vouching

So, I just can't see what all the attributes are that can be 'set' and 'get' or what the syntax is for setting and getting those attributes.

We've received comments that it is hard to tell what characters are used in the recovery tokens.

The system only uses a-f and 0-9 (hex encoding of a sha256 hash actually).

We should clarify this in both the email and on the recovery page (UI).