| 00:19.25 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 01:21.22 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 01:55.38 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-mrrispxcvabkzrvc) |
| 01:55.39 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:16.04 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 03:19.22 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 04:35.38 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 06:51.13 | *** join/#asterisk-dev vlad_starkov (~vlad_star@89.175.120.122) |
| 07:48.32 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.218.175.34) |
| 08:56.38 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginm.net) |
| 10:54.06 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 10:54.06 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:09.04 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 12:08.57 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 12:13.05 | *** join/#asterisk-dev Marquis42 (~mrbmw@d149-67-95-208.try.wideopenwest.com) |
| 12:19.38 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:28.06 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 12:28.06 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 12:33.07 | *** join/#asterisk-dev sliske_ (~sliske_@2001:4800:780e:510:6c33:9987:ff05:245f) |
| 12:42.39 | *** join/#asterisk-dev sliske_ (~sliske_@2001:4800:780e:510:6c33:9987:ff05:245f) |
| 13:10.36 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginm.net) |
| 13:28.39 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-141-181.user.veloxzone.com.br) |
| 13:29.09 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 13:36.23 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:8856:7a31:d5a8:40c) |
| 13:45.15 | *** join/#asterisk-dev newtonr (~newtonr@173-17-135-67.client.mchsi.com) |
| 13:45.15 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:56.18 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:56.18 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:02.33 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-wpjgnofqrhjzcmig) |
| 14:09.58 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-vwfcjbhcxvfjtsdk) |
| 14:47.34 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-dvicrhpzjtathcug) |
| 14:47.35 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:19.27 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 15:37.39 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 15:43.52 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 15:45.35 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-rwvwetlgmsflldsh) |
| 15:45.35 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 15:47.30 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 15:58.08 | mjordan | hi otherwiseguy/bye otherwiseguy |
| 15:58.20 | otherwiseguy | waves |
| 15:58.47 | otherwiseguy | Not sure what is up with connection. |
| 15:58.59 | mjordan | I had to bail on using anything other than XChat with FreeNode |
| 15:59.14 | mjordan | not sure what happened, but they may have tightened some form of flood protection |
| 15:59.15 | file | I blame... Google. |
| 15:59.24 | mjordan | file: always a good thing to blame |
| 16:00.34 | mjordan | jrose_atDigium: I'm assuming on r3447 that your responses to file don't mean that the issues are closed and that you're still working on it, right? |
| 16:00.52 | jrose_atDigium | Absolutely I'm still working on it |
| 16:01.05 | jrose_atDigium | I mentioned before that I couldn't reopen the issue though. |
| 16:01.15 | jrose_atDigium | Lack of permissions for whatever reason. |
| 16:02.01 | mjordan | jrose_atDigium: that's not really important :-P |
| 16:03.54 | jrose_atDigium | Hmmm, looks like I might have to add another set of tests for this. And add a legacy option. |
| 16:04.48 | tm1000 | mjordan: where does your fisheye instance live? |
| 16:05.04 | mjordan | tm1000: code.asterisk.org |
| 16:05.40 | tm1000 | mjordan: thanks |
| 16:27.59 | *** join/#asterisk-dev jemidy (~jemidy@nat/digium/x-ejwzdvyfkkomcovs) |
| 16:32.04 | mjordan | can someone take a poke at https://reviewboard.asterisk.org/r/3441/? |
| 16:53.28 | jrose_atDigium | jcolp+mjordan+wdoekes+putnopvut: So still on the subject of the current sendrpid issue, wdoekes suggested adding a 3rd option to the trust_id_outbound setting 'legacy' which would keep everything exactly as it is right now and having the 'no' value actually provide a set of more correct behaviors which will actually remove the related headers when we have unallowed callingpres values and we don't trust the endpoint with the info |
| 16:53.28 | jrose_atDigium | rmation. |
| 16:53.29 | jrose_atDigium | https://reviewboard.asterisk.org/r/3447/ |
| 16:54.20 | jrose_atDigium | I've updated some charts detailing what I think should be the expectations in each scenario going with the current tests that I've been working on. Does this seem like an appropriate solution for moving forward with this? |
| 16:55.56 | mjordan | just to clarify: if pres=prohibited, sendrpid=pai, we don't actually send anything |
| 16:56.00 | mjordan | in the PAI header |
| 16:56.39 | jrose_atDigium | That's what the behavior should be. Right now if pres=prohibited and sendrpid=pai, we send the anonymized PAI header. |
| 16:56.50 | jrose_atDigium | provided that trust_id_outbound is not yes. |
| 16:57.11 | jrose_atDigium | And if we go with the legacy option, we'll keep on sending the anonymous header when legacy is chosen. |
| 16:57.22 | jrose_atDigium | (and by default in 1.8-12) |
| 16:57.28 | file | right. |
| 16:57.34 | mjordan | formatting of the table aside, it looks correct to me. Legacy is what it is today; yes means we do no privacy; no means we honor the presentation values |
| 16:57.51 | file | agreed |
| 16:59.27 | jrose_atDigium | file: Do you have any opinion on what I said about the fromdomain issue? (should we make a point of using resetting to &p->ourip when fromdomain is set to an anonymous value when we trust the peer?) |
| 17:00.18 | file | if a legit fromdomain is specified we should always use it |
| 17:00.38 | jrose_atDigium | Yes, but do we consider 'anonymous.invalid' a 'legit' fromdomain? |
| 17:01.01 | file | That's not the right question. The right question is: "if I didn't set a fromdomain... why is it set to anonymous.invalid?" |
| 17:01.07 | jrose_atDigium | That too. |
| 17:01.28 | file | doing special stuff like you mentioned without understanding it is a recipe for disaster |
| 17:02.31 | mjordan | is there a reason to change the behavior? |
| 17:03.00 | file | mjordan, he's talking about when sending to a trusted peer - which is the new behavior |
| 17:03.53 | file | the fromdomain is set to anonymous.invalid for some reason, and since the code favors fromdomain (as it should) over the local address it gets placed into the header |
| 17:03.56 | jrose_atDigium | file: I think initreqprep() is setting the fromdomain to anonymous.invalid when it hasn't been set deliberately. I'm not sure why that is. |
| 17:04.50 | jrose_atDigium | Happens under the comment 'Allow domain to be overridden' |
| 17:06.13 | file | look for "Even if we are using RPID, we shouldn't leak information" |
| 17:06.47 | file | since we now have the ability to specify a peer as trusted, that is untrue in that case |
| 17:07.10 | jrose_atDigium | Well, I think the From field should probably remain untouched by this operation. |
| 17:07.31 | jrose_atDigium | We don't want that information exposed in the From field, but we do want it exposed in the RPID/PAI headers. |
| 17:08.54 | gtjoseph | If anyone's got some free time can you take a look at my spinlock review? https://reviewboard.asterisk.org/r/3405/ |
| 17:09.39 | jrose_atDigium | When locking ceases to make you dizzy, add spinning into the equation eh? |
| 17:10.18 | file | jrose_atDigium, I don't have a suggestion otherwise so maybe just a comparison is the answer... although if someone specifies that as their fromdomain, hilarity |
| 17:10.46 | file | gtjoseph, where/when do you envision that getting used? |
| 17:11.55 | gtjoseph | lock around the refcount in internal_ao2_ref. needed by weak containers. |
| 17:12.25 | gtjoseph | replacing the ast_atomic_fetchadd_int |
| 17:13.24 | jrose_atDigium | file: Perhaps I could do a pointer comparison instead of a string comparison to make sure that the anonymous.invalid specified is actually FROMDOMAIN_INVALID instead of a user specified anonymous.invalid? |
| 17:13.58 | jrose_atDigium | oh wait |
| 17:13.58 | jrose_atDigium | nevermind |
| 17:14.03 | jrose_atDigium | it does a string field set |
| 17:14.16 | file | gtjoseph, add your intentions to the review... and rmudgett will probably clamor to it |
| 17:14.31 | jrose_atDigium | He's out today unfortunately. |
| 17:14.44 | gtjoseph | will do |
| 17:15.08 | jrose_atDigium | I'll prod him on it when he gets back if no one else does. |
| 17:15.46 | file | gtjoseph, many of us can review it but since this is going to impact ao2 it would be better to have an overall discussion involving him first |
| 17:15.55 | gtjoseph | absolutely |
| 17:17.13 | file | jrose_atDigium, throw it up with an explanation in the code as a comment of why you are doing the comparison |
| 17:18.55 | jrose_atDigium | Will do. |
| 17:40.13 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 17:40.13 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 18:46.40 | mjordan | jrose_atDigium: whatever the defaults end up being, make sure it ends up getting noted on the review |
| 18:48.53 | jrose_atDigium | yeppers |
| 18:50.00 | tm1000 | jsmith: https://twitter.com/NerdDeuce |
| 18:50.32 | file | tm1000, did that finally show up on your radar? |
| 18:50.48 | tm1000 | file: yes jason found it actually |
| 18:50.48 | tm1000 | amusing. |
| 18:53.56 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginm.net) |
| 18:54.21 | Qwell | somebody pointed me there |
| 18:54.48 | pabelanger | "found" |
| 18:57.24 | mjordan | tm1000: yeah, that one showed up on mine as well. Strange. |
| 18:57.45 | tm1000 | it's paul. |
| 18:57.48 | tm1000 | pabelanger: :-p |
| 18:57.53 | tm1000 | (jk) |
| 19:09.42 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginm.net) |
| 19:39.41 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginm.net) |
| 19:49.54 | *** join/#asterisk-dev Marquis42 (~mrbmw@d149-67-95-208.try.wideopenwest.com) |
| 20:02.08 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.23.159.253) |
| 20:26.55 | jrose_atDigium | mjordan/jcolp/wdoekes/putnopvut: Posted updates for the sendrpid tests and the patch for adding trust_id_outbound=yes/no/legacy support |
| 20:46.52 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginm.net) |
| 22:01.19 | jrose_atDigium | https://reviewboard.asterisk.org/r/3379/ -- review on this issue has been stalled a while if anyone has a little time to give it another pass |
| 22:11.50 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 22:11.50 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:14.30 | jrose_atDigium | Thanks putnopvut |
| 22:15.00 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 22:15.03 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 22:21.53 | *** join/#asterisk-dev sliske_ (~sliske_@2001:4800:780e:510:6c33:9987:ff05:245f) |
| 22:29.00 | file | jrose_atDigium, trunk no longer builds |
| 22:29.08 | jrose_atDigium | :< |
| 22:29.13 | jrose_atDigium | Looking into it |
| 22:29.21 | file | app.c: In function ast_control_tone: |
| 22:29.23 | file | app.c:1207:2: error: res may be used uninitialized in this function [-Werror=maybe-uninitialized] |
| 22:29.23 | file | <PROTECTED> |
| 22:29.23 | file | <PROTECTED> |
| 22:31.20 | jrose_atDigium | Hmmm, it was still compiling for me when I committed it. Perhaps a difference in compiler versions... although I thought uninitialized variables were picked up by mine. |
| 22:31.35 | file | it may not be as smrt |
| 22:32.11 | file | ah you are shadowing |
| 22:32.34 | jrose_atDigium | Yeah, I see it |
| 22:32.37 | jrose_atDigium | That was silly. |
| 22:32.45 | jrose_atDigium | I'll have it fixed in a short bit. |
| 22:33.12 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.23.159.253) |
| 22:43.08 | jrose_atDigium | file: Should be fixed now. |
| 22:45.30 | file | merci |
| 22:45.34 | file | now I can remember what I was going to do |
| 23:19.03 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-vwfcjbhcxvfjtsdk) |
| 23:22.11 | newtonr | if someone is really bored I have a review you can look at :) https://reviewboard.asterisk.org/r/3464/ |
| 23:22.26 | newtonr | it not complex of course, just some sound prompt junk |
| 23:33.09 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |