At least on the experimental 3.0.0 trust router package, a trustrouter service is not created when the deb is installed. The tids.service is installed, but fails to work (there is a separate issue for this). I'm not sure whether there is a connection between these.

Launchpad Details: #LP1701589 Jennifer Richards - 2017-06-30 14:39:49 +0000

In several places in the GSS code in gsscon/, status messages/errors are reported via fprintf(stderr,...). These should instead use a logging mechanism so they can be integrated with log messages from other components of the system.

Launchpad Details: #LP1582744 Jennifer Richards - 2016-05-17 14:17:51 +0000

A number of unit test programs are built as part of the trust router code base. Most of these are only run manually. These should be run automatically (e.g., via "make check").

Launchpad Details: #LP1635302 Jennifer Richards - 2016-10-20 14:59:28 +0000

Given that the classic problem of the DISPLAY variable being passed (somehow, somewhere, don't ask me how) along into the environment that TIDC (and the TID library), TIDS and TRUST_ROUTER consume crops up time and again, can we perhaps get those binaries to sanitize their environment to explicitly UNSET the DISPLAY variable to avoid credential retrieval from failing?

We know those binaries will always be invoked from a non-X environment, so why don't they simply make sure DISPLAY is not set to avoid unfavourable interactions with DBUS and X?

Launchpad Details: #LP1689568 Stefan Paetow - 2017-05-09 14:34:53 +0000

From 1.0 to do list.

Launchpad Details: #LP1192662 Trish Zagarella - 2013-06-19 18:43:33 +0000

A substantial number of errors are found by running valgrind on the trust_router or tids binaries. Many of the leaks are likely harmless because they occur only in TID handling sub-processes, which are short-lived. It would still be nice to clean these up or verify that they are, in fact, tolerable.

Running valgrind to see these: as root, "libtool --mode=execute valgrind --leak-check=full --track-origins=yes [options...]"

Launchpad Details: #LP1648121 Jennifer Richards - 2016-12-07 15:37:48 +0000

University of Edinburgh is seeing a lot of connections to the trust router in a CLOSE_WAIT state:

I've noticed a steadily increasing amount of zombie connections between
our Moonshot IdP and the trust router:

tcp 1 0 moonshot-test.is.ed.a:49845
tr1.moonshot.ja.net:12309 CLOSE_WAIT 1224/radiusd
tcp 1 0 moonshot-test.is.ed.a:50068
tr1.moonshot.ja.net:12309 CLOSE_WAIT 1224/radiusd
tcp 1 0 moonshot-test.is.ed.a:50874
tr1.moonshot.ja.net:12309 CLOSE_WAIT 1224/radiusd

These are all sitting in the CLOSE_WAIT state.
I'm currently at 838 connections and counting. Any idea what's causing this?

According to Sam, this is something in the trust router code.

Launchpad Details: #LP1454166 Stefan Paetow - 2015-05-12 09:22:45 +0000

Today I made a spelling mistake when I set up a new trust router infrastructure. I misspelled the domain constraint for the down-stream trust router in the infrastructure, using 'l2tr.level1.localdomain' when its actual name is 'l2tr.level2.localdomain'.

The consequence of this is that I saw an 'Internal Processing Error' during an initial TIDC request to check whether the infrastructure was set up correctly.

The log and config from the L1TR (upstream) and the config from the L2TR (down-stream) trust routers are attached.

The command used on the down-stream trust router was this:

tidc l2tr.level2.localdomain tr.level2.realm apc.trust.realm apc.trust.realm

Launchpad Details: #LP1464800 Stefan Paetow - 2015-06-13 00:33:34 +0000

As config errors cause the trust router to fail to start, it would be useful if the trust_router binary could be invoked with an option (FreeRADIUS uses -C) that simply parses the config and exits, returning 0 if the configuration is valid.

Launchpad Details: #LP1324047 Adam Bishop - 2014-05-28 10:00:32 +0000

Makefile.am defines several groups of source files (common_srcs, tid_srcs, trp_srcs) which are intended to collect related collections of code for easy inclusion in the various binaries in the project. Currently, these are interdependent and must either all be included or none. To fix this bug, either these should be separated into groups that can be individually (or all) included in a binary build specification, or this illusory separation should be eliminated.

It is probably ok if both tid_srcs and trp_srcs depend on common_srcs.

This problem occurs at least because tr_msg.c contains code for encoding/decoding both TRP and TID messages. This could be eliminated by abstracting the encoder/decoder interface and moving the actual encoder/decoder functions into the TRP and TID code. This is unquestionably the clean solution, though it is unclear if it is a worthwhile investment of effort since it is unlikely we will add additional protocols that might benefit from the work/additional complexity.

Formerly, TID-related code was built into a library, libtr_tid.la. A simple attempt to create a parallel libtr_trp.la library failed due to the libraries repeating code common to the two. Another option may be to reintroduce a library housing both TID and TRP code. It's not clear whether this offers meaningful benefits without further reorganization of the project.

Launchpad Details: #LP1651519 Jennifer Richards - 2016-12-20 16:49:46 +0000

A community is configured twice in the freeradius proxy on our RP -- once in sites-available/abfab-tls and once in mods-available/realm. What does each one do? Why are there two?

Also, if we want communities to work well, we need to have a way for RPs to do queries (through their freeradius proxy) for different communities.

Further discussion is found at https://github.com/painless-security/moonshot-portal/issues/772.

Launchpad Details: #LP1694467 Mark Donnelly - 2017-05-30 15:34:33 +0000

When forwarding a TID request using a CoI other than the APC, the trust router looks up the route using the CoI name, not the APC name it translates to. This generally causes failure to find a route.

The service / RP realm is found correctly.

Launchpad Details: #LP1704184 Jennifer Richards - 2017-07-13 17:38:19 +0000

The tr_create_dh_params function (in common/tr_dh.c) defines the following at the top of the function (from line 94 onwards):

  if (NULL == (dh = DH_new()))
    return NULL;

  if ((NULL == (dh->g = BN_new())) ||
      (NULL == (dh->p = BN_new())) ||
      (NULL == (dh->q = BN_new()))) {
    DH_free(dh);
  }

  BN_set_word(dh->g, 2);
  dh->p = BN_bin2bn(tr_2048_dhprime, sizeof(tr_2048_dhprime), NULL);
  BN_rshift1(dh->q, dh->p);

The first if () is uncontroversial. It is pretty clear. However, the second does not return after freeing the 'dh' structure... I'm sure it's never happened before that BN_new() returns a failure (NULL), but this would cause a crash, no?

Should there be a 'return NULL;' after the 'DH_free(dh);' line? I suspect yes?

Launchpad Details: #LP1730679 Stefan Paetow - 2017-11-07 14:58:35 +0000

In the traces in https://bugs.launchpad.net/moonshot-tr/+bug/1464800, we see that even in an error situation, the tids is returning server blocks. That's almost certainly wrong.
Also, I wonder whether the intermediate trust routers should trim out server blocks on error responses to avoid a covert-channel-like-thing where we pretend to the middle something failed, but establish a key anyway.

Launchpad Details: #LP1464804 Sam Hartman - 2015-06-13 01:10:14 +0000

I believe a change in behavio(u)r was introduced along with the initial implementaiton of the Dynamic Trust Router protocol. In the past, a request for an IdP realm without a configured AAA server would be sent to the configured default AAA server. Currently, this will result in an error being returned.

To fix this, the old behavio(u)r should be restored.

I'm not certain that the new behavio(u)r is described accurately here, need to verify this as well.

Launchpad Details: #LP1643681 Jennifer Richards - 2016-11-21 20:16:57 +0000

The Debian package build system reports that the libtr-tid2 package is linked against libraries whose symbols it does not use. I believe this is correct and these could be removed.

dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/libtr-tid2/usr/lib/x86_64-linux-gnu/libtr_tid.so.2.2.0 was not linked against libsqlite3.so.0 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/libtr-tid2/usr/lib/x86_64-linux-gnu/libtr_tid.so.2.2.0 was not linked against libevent-2.0.so.5 (it uses none of the library's symbols)

Launchpad Details: #LP1704884 Jennifer Richards - 2017-07-17 22:17:39 +0000

Realm / community memberships (in the upcoming community flooding release) are implemented in a functional but inefficient manner. This should suffice for modestly sized federations, but will not scale well. This should be reimplemented in a more scalable fashion.

Launchpad Details: #LP1635326 Jennifer Richards - 2016-10-20 15:39:19 +0000

In the logs in the trust router, it would be a really good idea to log the remote (incoming) IP address that the request is coming from. Currently I see something like this:

tids_handle_connection: Connection authorized!
tids_read_request():Request Received, 1241 bytes.
tr_tids_req_handler: Request received (conn = 6)! Realm = ov-apc.moonshot.ja.net, Comm = ov-apc.moonshot.ja.net

Ideally I'd like to see something like this:

tids_handle_connection: Connection authorized!
tids_read_request():Request Received from 212.219.179.131, 1241 bytes.
tr_tids_req_handler: Request received (conn = 6)! Realm = ov-apc.moonshot.ja.net, Comm = ov-apc.moonshot.ja.net

That way we know which IP has requested the connection. I don't know if this is possible when you have a proxy in front of the trust router (i.e. the way we do to balance incoming requests), but it would be worth asking Adam?

Launchpad Details: #LP1722349 Stefan Paetow - 2017-10-09 16:39:35 +0000

"Remote" realms---realms for which the trust router knows only that a realm exists---were introduced to allow testing of trust route flooding before community flooding was implemented. As far as I know, there is no plausible use case for these now that community information is shared between peers. It would be a good idea to remove these. I don't think it should affect any configurations in actual use.

Correction/clarification: The remote realms are needed to allow a locally defined community to include remote realms. It would be possible to do away with the entries in the "realms" section, instead inferring the existence of remote realms when an unknown realm is listed in a "community" definition.

There is a balance to strike between ease of use and protection against problems created by typos. It is somewhat inconvenient to have to list remote realms twice, but it does avoid a single error from creating an imaginary realm and silently hiding the fact that the actual realm is not being properly included in the community.

Launchpad Details: #LP1699882 Jennifer Richards - 2017-06-22 19:39:26 +0000

Encountered a segfault when preparing a community update for a TRP peer:

trps_update: rc=0 after attempting update.
trp_rtable_get_realm_entries: entered.
trp_route_set_triggered: setting route to apc.sports.psec.us/apc.sports.psec.us through  to not triggered
tr_fspec_matches: Field info_type value "comm" matches "comm" for trp_inbound filter.
tr_fspec_matches: Field comm value "apc.sports.psec.us" matches "*" for trp_inbound filter.
trps_handle_update: handling community inforec.
trps_compute_expiry: tv_sec=109903, interval=30, small_factor*interval=90
trps_handle_inforec_comm: added RP realm redsox.com to comm apc.sports.psec.us (origin tr.qa.painless-security.com:12308).
trp_rtable_get_realm_entries: entered.
trps_get_selected_route: entered. trps=0x55baa7be09f0, comm=0x55baa7be4e10, realm=0x55baa7be5020
trp_rtable_get_realm_entries: entered.
trp_rtable_get_selected_entry: looking through route table entries for realm apc.sports.psec.us.
trp_rtable_get_selected_entry: ii=0.
trps_update_one_peer: preparing triggered update for tr.qa.painless-security.com:12308
trps_update_one_peer: selecting route updates for tr.qa.painless-security.com:12308.
trp_rtable_get_realm_entries: entered.
trp_rtable_get_selected_entry: looking through route table entries for realm apc.sports.psec.us.
trp_rtable_get_selected_entry: ii=0.
trps_select_realm_update: tr.qa.painless-security.com:12308 vs 
trps_update_one_peer: selecting community updates for tr.qa.painless-security.com:12308.
trps_update_one_peer: no updates for tr.qa.painless-security.com:12308
trps_update: rc=0 after attempting update.
trp_rtable_get_realm_entries: entered.
trp_route_set_triggered: setting route to apc.sports.psec.us/apc.sports.psec.us through  to not triggered
tr_connection_update: checking peer connections.
tr_connection_update: checking peer connections.
mons_sweep_procs: monitoring process 11883 terminated.
mons_sweep_procs: monitoring process 11883 terminated by signal 11.
tr_gss_handle_connection: Attempting to accept trustmonitor connection on fd 19.
tr_gss_auth_connection: Beginning passive authentication as [email protected]
tr_trps_update: sending scheduled route/community updates.
trps_update_one_peer: preparing scheduled update for tr.qa.painless-security.com:12308
trps_update_one_peer: selecting route updates for tr.qa.painless-security.com:12308.
trp_rtable_get_realm_entries: entered.
trp_rtable_get_selected_entry: looking through route table entries for realm apc.sports.psec.us.
trp_rtable_get_selected_entry: ii=0.
trps_select_realm_update: tr.qa.painless-security.com:12308 vs 
trp_upd_add_inforec: adding record.
trps_update_one_peer: selecting community updates for tr.qa.painless-security.com:12308.
Segmentation fault

Conflicting configuration directives in the configuration files should at least cause a warning to the user. For example, if there are multiple definitions of hostname or TID / TRP port, these will silently overrule each other, the last one to be loaded being put into the active configuration. This is probably not intended by the user, so a warning should be issued to inform the user of the situation and what has actually been configured. Alternatively, the configuration could be rejected.

Unrecognized entries in the configuration files are currently ignored; these should result in warnings because they likely represent erros, but might conceivably be intended.

Launchpad Details: #LP1635323 Jennifer Richards - 2016-10-20 15:33:10 +0000

We are currently using TIDS example code in the AAA Server. This code should either be integrated into freeradius, or it should be extended to include a config file, normal unix command line options, etc.

Launchpad Details: #LP1294297 Margaret Cullen - 2014-03-18 19:15:58 +0000

The new RHEL/CentOS 7 tids.service file does not use the existing RedHat/CentOS 6 files for the TIDS service. This causes an eventual failure:

1. It should read /etc/sysconfig/tids, not /etc/default/tids (the Debian location)
2. ExecStart should use: /usr/bin/tids ${TIDS_SERVER_IP} ${TIDS_GSS_NAME} ${TIDS_SERVER_NAME} (currently it uses the Debian-style "${ipaddr} ${gssname} ${hostname}" command-line)

Should we tweak the packages to fix this to RHEL 6 style or shall we break with convention to match Debian and RHEL 7 up?

Launchpad Details: #LP1598856 Stefan Paetow - 2016-07-04 14:01:21 +0000

Various functions in the tid_* modules follow naming conventions different from the rest of the trust router code (e.g., tid_srvr_get_path() should be tid_srvr_blk_get_path()). This needs to be cleaned up.

Launchpad Details: #LP1646180 Jennifer Richards - 2016-11-30 16:38:43 +0000

If the TIDC configuration in FreeRADIUS is not perfect, it segaults when trying to call the TIDC.

#0  0x00007fffefddcbf8 in ?? () from /usr/lib/x86_64-linux-gnu/libtr_tid.so.0
No symbol table info available.
#1  0x00007fffefddb158 in tidc_open_connection () from /usr/lib/x86_64-linux-gnu/libtr_tid.so.0
No symbol table info available.
#2  0x00007fffeffe3917 in tr_query_realm (q_realm=q_realm@entry=0x96e471 "apc.moonshot.ja.net", q_community=0x8fa8f0 "none", q_rprealm=0x8faaf0 "none", q_trustrouter=0x8fb070 "none") at src/modules/rlm_realm/trustrouter_integ.c:214
        conn = 0
        rc = <optimized out>
        gssctx = <optimized out>
        cookie = 0x969d30
#3  0x00007fffeffe2f2c in check_for_realm (returnrealm=0x7fffebc8f098, request=0x969600, instance=0x8fa4b0) at src/modules/rlm_realm/rlm_realm.c:172
        username = 0x96e470 ""
        vp = <optimized out>
        realm = 0x0
        namebuf = 0x96e470 ""
        realmname = <optimized out>
        ptr = <optimized out>
#4  check_for_realm (instance=0x8fa4b0, request=0x969600, returnrealm=0x7fffebc8f098) at src/modules/rlm_realm/rlm_realm.c:68
        inst = <optimized out>
#5  0x00007fffeffe2fcb in mod_authorize (instance=<optimized out>, request=0x969600) at src/modules/rlm_realm/rlm_realm.c:392
        rcode = <optimized out>
        realm = 0x0
#6  0x000000000041ed9e in call_modsingle (request=0x969600, component=1, sp=<optimized out>) at src/main/modcall.c:311
        myresult = <optimized out>
        blocked = <optimized out>
#7  modcall (component=component@entry=1, c=c@entry=0x91adc0, request=request@entry=0x969600) at src/main/modcall.c:785
        cursor = {first = 0x0, found = 0x0, last = 0xffffffff, current = 0x0, next = 0x0}
        myresult = <optimized out>
        mypriority = 2
        stack = {pointer = 1, priority = {<optimized out> <repeats 32 times>}, result = {<optimized out> <repeats 32 times>}, children = {<optimized out> <repeats 32 times>}, start = {<optimized out> <repeats 32 times>}}
        parent = 0x91adc0
        child = 0x91afc0
        if_taken = 0
        was_if = 0
#8  0x000000000041ceec in indexed_modcall (comp=comp@entry=1, idx=idx@entry=0, request=request@entry=0x969600) at src/main/modules.c:758
        rcode = <optimized out>
        list = 0x91adc0
        server = <optimized out>
#9  0x000000000041d8df in process_authorize (autz_type=autz_type@entry=0, request=request@entry=0x969600) at src/main/modules.c:1640
No locals.
#10 0x000000000040ee90 in rad_authenticate (request=0x969600) at src/main/auth.c:426
        namepair = <optimized out>
        check_item = <optimized out>
        auth_item = 0x0
        module_msg = <optimized out>
        tmp = <optimized out>
        result = <optimized out>
        autz_retry = 0 '\000'
        autz_type = 0
#11 0x000000000042ac35 in request_running (action=1, request=0x969600) at src/main/process.c:1186
No locals.
#12 request_running (request=0x969600, action=1) at src/main/process.c:1155
No locals.
#13 0x00000000004258c3 in request_handler_thread (arg=0x9378a0) at src/main/threads.c:685
        self = 0x9378a0
#14 0x00007ffff62b2b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#15 0x00007ffff5b7ea7d in clone () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#16 0x0000000000000000 in ?? ()
No symbol table info available.

Launchpad Details: #LP1260800 Adam Bishop - 2013-12-13 16:59:11 +0000

If a disconnected dynamic trust routing peer makes an inbound connection to us, it would be a good idea to immediately attempt to make an outbound connection back. At present, that will not happen until the connection update timer expires. Depending on that configuration, this change could considerably reduce the delay before communication is reestablished to a newly reachable peer.

Launchpad Details: #LP1635324 Jennifer Richards - 2016-10-20 15:36:35 +0000

The show routes command only lists locally defined routes to AAA servers, even when the routing table contains remote routes discovered via TRP.

This should display all routes.

Occasionally, we get a "Connection reset by peer" when authenticating. This has only happened (so far) in cases were subsequent authentications work, so it may have to do with state priming and/or the potential failure is close to completing the authentication.

Subsequent attempts work.

Here is a section of the log where it happens:

Opening TIDC connection to tr.qa.painless-security.com:0
Waking up in 0.3 seconds.
gss_connect: Connecting to host 'tr.qa.painless-security.com' on port 12309
Waking up in 0.4 seconds.
Waking up in 0.7 seconds.
Waking up in 1.1 seconds.
Waking up in 1.6 seconds.
Waking up in 2.5 seconds.
tidc_fwd_request: Sending TID request:

{"msg_type": "tid_request", "msg_body": {"rp_realm": "yankees.com", "dh_info": {"dh_p": "FFFFFFFFFFFFFFFFC90FDAA22168C234C4C6628B80DC1CD129024E088A67CC74020BBEA63B139B22514A08798E3404DDEF9519B3CD3A431B302B0A6DF25F14374FE1356D6D51C245E485B576625E7EC6F44C42E9A637ED6B0BFF5CB6F406B7EDEE386BFB5A899FA5AE9F24117C4B1FE649286651ECE45B3DC2007CB8A163BF0598DA48361C55D39A69163FA8FD24CF5F83655D23DCA3AD961C62F356208552BB9ED529077096966D670C354E4ABC9804F1746C08CA18217C32905E462E36CE3BE39E772C180E86039B2783A2EC07A28FB5C55DF06F4C52C9DE2BCBF6955817183995497CEA956AE515D2261898FA051015728E5A8AACAA68FFFFFFFFFFFFFFFF", "dh_g": "02", "dh_pub_key": "8A7195FF0B554595F33900ADC4560A2006A2F63ACFF89DEADF599701D03C8FAD2EAB5C04DC49A6D3BE887112B594879848BD295365F378D5B2A1B4AE1E278B24FC8105170E3F0EA17EE57002F2A2D3CDF645544AFAACD2DD2C6085187325097B9B226BD04D8227EE47C9BDFD569AEE542783EF0D396E8B63D6FFC2FE1021C4BDFE513A80ECC0E985D950354C93DA0C18339020D3228A2E0A1DFAB2BC6F958929E07EF9A9A582A53456A554C39130023D33A37BA673BFE986ACF43B2E2F2481F607EE686B73400151A7A9B67BA836E31C348037ECBD2D7D7589E2CC17E8416A401DA03914E873B92C05965667C19E3838CE7996D278C144B5E854244EF3EF93AB"}, "target_realm": "is.evil4.us", "community": "ov-apc.communities.moonshot.ja.net"}}

ReadBuffer failed: Connection reset by peer (err = 104)
ReadToken failed: Connection reset by peer (err = 104)
ReadToken failed: Connection reset by peer (err = 104)
Error in tidc_send_request, rc = -1.
(7) suffix: No such realm "is.evil4.us"

Launchpad Details: #LP1694466 Mark Donnelly - 2017-05-30 15:31:20 +0000

The response to the show communities monitoring request lists no "sources" for some realms (see the "nymets.com" RP realm in the snippet below). The "sources" entry indicates the source that led the trust router to include a realm in a community. Every realm must have at least one source (and when peering is enabled, may have multiple).

Need to figure out what's going on with this. The source should be "file", like for the "redsox.com" entry.

{
    "code": 0,
    "message": "success",
    "payload": {
        "communities": [
            {
                "type": "apc",
                "expiration_interval": 120,
                "name": "apc.sports.psec.us",
                "rp_realms": [
                    {
                        "realm": "nymets.com",
                        "sources": []
                    },
                    {
                        "realm": "redsox.com",
                        "sources": [
                            {
                                "origin": "file"
                            }
                        ]

In an X environment, i.e. Gnome, the UI for the Software Updater shows a description for each package. For the trust_router-libs package, it shows the title of "Libraries needed by %{Name}", not "Libraries needed by Moonshot Trust Router" as expected.

I'm guessing this is purely a build issue, nothing that affects the operation of the package. I've attached a screenshot of this.

Launchpad Details: #LP1462971 Stefan Paetow - 2015-06-08 10:50:30 +0000

If a non-existent SSL certificate is pointed to by /etc/radsec.conf, trust_router fails with an confusing sequence of error messages. These are correct, but a meaningful error from trust_router itself should appear.

trp_connection_auth: beginning passive authentication
In gsscon_passive_authenticate(), inNameBuffer =
SSL: error:02001002:system library:fopen:No such file or directory
SSL: error:20074002:BIO routines:FILE_CTRL:system lib
SSL: error:140DC002:SSL routines:SSL_CTX_use_certificate_chain_file:system lib
tlscreatectx: Error initialising SSL/TLS (certfile issues) in TLS context gss-eap
trust_router: util_radius.cpp:880: OM_uint32 gssEapRadiusMapError(OM_uint32*, rs_error*): Assertion `(err != __null)' failed.

Launchpad Details: #LP1595972 Jennifer Richards - 2016-06-24 14:29:57 +0000

On my dev branch, I have begun checking the exit status of the forked processes that handle TID requests. These are consistently being terminated by a SIGSEGV rather than exiting cleanly. This is not a disaster because it happens after the TID response has been sent, at least most of the time. However, it would be useful for these processes to exit cleanly so they can indicate to the parent process whether they succeeded or encountered a real error.

The trust router now supports runtime reconfiguration when a configuration file is changed. At present, any changes to the configuration file cause the dynamic route and community tables to be flushed. This is safe, but overly conservative and may lead to unnecessary temporary service outages until the tables reconverge. It would be preferable only to flush the route/community tables if the configuration changes affect these.

Launchpad Details: #LP1635313 Jennifer Richards - 2016-10-20 15:15:10 +0000

There is a bug in the trust router's realm / community sweep that causes the trust router to terminate with a segmentation fault.

This occurs when the last realm or community in the linked list being swept is unreferenced and being purged. With some configurations, this will happen every time shortly after start up. It may also happen randomly if trust peering is in use.

This affects at least versions 3.0 - 3.0.2

A fix for this will be out shortly.

Launchpad Details: #LP1751320 Jennifer Richards - 2018-02-23 16:35:52 +0000

If the trust router's configured hostname or tid/trp ports are changed, these will be automatically loaded, but not actually changed. This should result in proper reconfiguration and rebinding to the new ports (while, ideally, completing any in-progress transactions on the previously configured ports)

Launchpad Details: #LP1635318 Jennifer Richards - 2016-10-20 15:22:57 +0000

Currently, the TIDS command line requires that we specify the gss name of the trustrouter that will contact the tids.
However, when credentials change in the moonshot management portal, the gss name also changes.
As a result, if a trustrouter needs to be rekeyed, all tids need to be reconfigured.

This is clearly the wrong answer. We need to do something better.

Options include:

• Specify a wildcard match say *@apc_realm and have a radius attribute indicate whether the tids should trust the connection

• update the portal to keep credential names when rekeying the trust router

• Have the portal have user names like cred-xxx-org-yyy@apc_realm and do a whildcard match of *-org-yyy@apc_realm

Launchpad Details: #LP1320993 Sam Hartman - 2014-05-19 19:45:13 +0000

Debian 7 official moonshot-trustrouter packages. Used from FR.

How to reproduce: although it happened to me used from FR, it can be easily reproducible if you just try to execute "tidc" using a invalid (such as "nevermind").

Example:

tidc nevermind um.es jisc.net jisc2-t3-apc.lxc
TIDC Client:
Server = nevermind, rp_realm = um.es, target_realm = jisc.net, community = jisc2-t3-apc.lxc, port = 12309
Warning: dh_check failed with 8
: the g value is not a generator
Segmentation fault (core dumped)

Backtrace:

#0  gsscon_connect (inHost=inHost@entry=0x7fffffffeecd "nevermind", inPort=inPort@entry=12309, inServiceName=inServiceName@entry=0x7ffff7bd94d7 "trustidentity", outFD=outFD@entry=0x7fffffffeb6c, 
    outGSSContext=outGSSContext@entry=0x7fffffffeba8) at gsscon_active.c:92
        err = <optimized out>
        fd = -1
        majorStatus = <optimized out>
        minorStatus = 0
        minorStatusToo = 0
        hp = <optimized out>
        saddr = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "`0`\000\000\000\000"}
        serviceName = 0x0
        clientName = 0x0
        clientCredentials = 0x0
        gssContext = 0x0
        actualFlags = 0
        inputTokenBuffer = 0x0
        inputTokenBufferLength = 0
        inputToken = {length = 140737488350950, value = 0x3015}
        nameBuffer = {length = 0, value = 0x7ffff7dea9c2}
        inputTokenPtr = 0x0
        name = <optimized out>
        EAP_OID = {length = 1, elements = 0x0}
#1  0x00007ffff7bd45fd in tidc_open_connection (tidc=tidc@entry=0x603060, server=server@entry=0x7fffffffeecd "nevermind", port=port@entry=12309, gssctx=gssctx@entry=0x7fffffffeba8) at tid/tidc.c:77
        err = 0
        conn = -1
        use_port = 12309
#2  0x0000000000400c94 in main (argc=<optimized out>, argv=<optimized out>) at tid/example/tidc_main.c:136
        tidc = 0x603060
        server = 0x7fffffffeecd "nevermind"
        rp_realm = 0x7fffffffeed7 "um.es"
        realm = 0x7fffffffeedd "jisc.net"
        coi = 0x7fffffffeee6 "jisc2-t3-apc.lxc"
        port = 12309
        conn = 0
        rc = <optimized out>
        gssctx = <optimized out>

Launchpad Details: #LP1691230 Alejandro Perez - 2017-05-16 18:30:35 +0000

The TID server (tids) returns an error with message "internal processing error" when handling a request that has only domain constraints or only realm constraints. An otherwise identical request that has both domain and realm constraints, or that has neither, will be handled correctly.

To reproduce: configure a trust router to have an RP realm with a tid_incoming filter with both realm and domain constraints. Issue a TID request with tidc and verify that it succeeds. Reconfigure the trust router without one or the other and the request should fail. Remove both and it should succeed.

Launchpad Details: #LP1703943 Jennifer Richards - 2017-07-12 17:43:18 +0000

If there is an issue with an IdP realm:

...
tr_cfg_parse_idp_realms: IDP realm configured: lboro.ac.uk.
tr_cfg_parse_one_idp_realm: Can't parse APCs for realm moonshot.ed.ac.uk .
tr_cfg_find_idp: Found amelie.dev.ja.net.
...

The configuration parser immediately returns and moves on to the next configuration stage, even if there are more IdP's to process.

Launchpad Details: #LP1403845 Adam Bishop - 2014-12-18 11:31:07 +0000

Originally reported by mrw42 on github:

There is also a bug in an error message where an APC membership error lists the COI name in the message, instead of the APC name (should use community from forwarded request, not from original request).

Launchpad Details: #LP1666601 Jennifer Richards - 2017-02-21 17:11:26 +0000

Trust router now supports runtime reconfiguration, triggered by changes to its configuration files. Need to behave reasonably when various update intervals are changed in the configuration file, probably by immediately restarting the timer that triggers the next update. Currently, changes do not take effect until the current interval expires (which could require restarting the trust router if a very long interval is accidentally configured.)

Launchpad Details: #LP1635308 Jennifer Richards - 2016-10-20 15:09:16 +0000

A customer on Ubuntu 16 is using TIDS 1.5.2 (spun from the official source packages) and reports the following:

-- begin --

We have a real problem with runaway tids processes. I enabled the provided systemd service, and it starts up OK, but then over time we accumulate tids processes, each of which is using as much CPU as it can (so the first uses 100% of one CPU, the second uses 100% of the second CPU, and then 100% of CPU is being spent on tids processes). restarting the tids service kills them all and then all is well again.

It's like tids is doing something bad after each transaction, and sitting in a tight loop rather than exiting?

example strace of one of these processes:

root@idp-01:~# strace -f -p 29901
strace: Process 29901 attached with 4 threads
strace: [ Process PID=29901 runs in x32 mode. ]
[pid 29904] futex(0x1fe354c, FUTEX_WAIT_PRIVATE, 1, NULL <unfinished ...>
[pid 29903] futex(0x1f2cb4c, FUTEX_WAIT_PRIVATE, 1, NULL <unfinished ...>
[pid 29902] futex(0x1e6afbc, FUTEX_WAIT_PRIVATE, 1, NULL^Cstrace:
Process 29901 detached
strace: Process 29902 detached
<detached ...>
strace: Process 29903 detached
strace: Process 29904 detached

-- ends --

We've spun a build of the 2.1.1 package and have provided it to the customer for checking, but this should be documented for possible fixing.

Launchpad Details: #LP1689591 Stefan Paetow - 2017-05-09 16:18:32 +0000

Installing moonshot-trust-router via apt on Debian 8 gives the following error:

Setting up moonshot-trust-router (1.5.12deb80) ...
Job for tids.service failed. See 'systemctl status tids.service' and 'journalctl -xn' for details.
invoke-rc.d: initscript tids, action "start" failed.
dpkg: error processing package moonshot-trust-router (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
moonshot-trust-router
E: Sub-process /usr/bin/dpkg returned an error code (1)

Looking at the logs:

systemctl status tids.service

● tids.service - Trust Identity Protocol Server
Loaded: loaded (/lib/systemd/system/tids.service; disabled)
Active: failed (Result: start-limit) since Fri 2016-09-02 19:09:59 UTC; 20s ago

Sep 02 19:09:59 ip-172-31-37-133 systemd[1]: Failed to start Trust Identity Protocol Server.
Sep 02 19:09:59 ip-172-31-37-133 systemd[1]: Unit tids.service entered failed state.
Sep 02 19:09:59 ip-172-31-37-133 systemd[1]: tids.service holdoff time over, scheduling restart.
Sep 02 19:09:59 ip-172-31-37-133 systemd[1]: Stopping Trust Identity Protocol Server...
Sep 02 19:09:59 ip-172-31-37-133 systemd[1]: Starting Trust Identity Protocol Server...
Sep 02 19:09:59 ip-172-31-37-133 systemd[1]: tids.service start request repeated too quickly, refusing to start.
Sep 02 19:09:59 ip-172-31-37-133 systemd[1]: Failed to start Trust Identity Protocol Server.
Sep 02 19:09:59 ip-172-31-37-133 systemd[1]: Unit tids.service entered failed state.

After this, the package is left in the "not fully installed or removed" state.

Launchpad Details: #LP1619782 Jennifer Richards - 2016-09-02 19:55:20 +0000

The port configured for a AAA server is not always respected, in some cases using the default port regardless of configuration. This needs to be fixed.

Launchpad Details: #LP1635317 Jennifer Richards - 2016-10-20 15:20:39 +0000

(No action required on this; just noting this down so I remember to investigate it further).

When a non-existent IdP realm is requested from a trust router, I don't get the error I expect, and the trust router doesn't abort the request as early as I would expect.

The end result is correct (send an error and close the connection) but I think its doing more work than it should.

Launchpad Details: #LP1564589 Adam Bishop - 2016-03-31 19:35:46 +0000

Found 4-5 trust_router processes, each running at 50-100% of the CPU, after the trust router was running for a while.

Perhaps related to #4.

Had made a number of unsuccessful connection attempts, and was peered.

The number of "internal" configuration options for the trust router is growing. For better usability it would be helpful to normalize the naming of these. Currently "logging" has its own sub-structure. There are a growing number of options for the TID and dynamic TR protocols that introducing sub-structures for these might reduce the length of parameter names and make their purposes clearer.

Launchpad Details: #LP1648124 Jennifer Richards - 2016-12-07 15:41:33 +0000

there's no postrm script to clean up /var/lib/trust_router and remove the user on purge.

Launchpad Details: #LP1334718 Sam Hartman - 2014-06-26 15:17:51 +0000

Dynamic trust router protocol-specific configuration options should be sanity checked / validated to ensure a reasonably functional configuration is being used.

Launchpad Details: #LP1635315 Jennifer Richards - 2016-10-20 15:19:05 +0000

The filters implemented in tr_filter.c/.h are currently implemented using a fixed number of entries for the number of filter lines, specs within each filter line, and matches for each spec. This was done for expediency, but should be refactored to allow arbitrary numbers of entries at each level.

The original implementation used 8 for each, but that was immediately too small for the number of matches in our test configuration (specifically, we needed more matches). I will increase that for now.

Launchpad Details: #LP1702386 Jennifer Richards - 2017-07-05 01:26:16 +0000