>
> Hi Frediano,
>
> Note that there still is another call to red_stream_remove_watch,
> (in reds_handle_ssl_accept), so consider changing the subject.
>
Yes, but this one is not handling link but SSL/TLS.
> One comment below.
>
>
> On 12/19/2017 03:38 PM, Frediano Ziglio wrote:
> > Signed-o
>
> The .pdb files contain the debug information for the drivers. They
> increase significantly the size of the installer, so it's better not to
> ship them.
On the other side bug report will contain much less informations.
Not really sure about it.
> ---
> Makefile | 2 +-
> 1 file changed, 1
>
> If these paths are unquoted, and the path contains spaces (C:\Program
> Files (x86)\...), this could be exploited by putting a binary with a
> crafted name (C:\Program.exe), leading to privilege escalation as this
> is a service that is being started.
>
> https://www.commonexploits.com/unquot
On Tue, Dec 19, 2017 at 11:38:26AM +, Frediano Ziglio wrote:
> In case mcc->priv->initial_channels_list_sent is false we didn't
> marshall any message so we should not call
> red_channel_client_begin_send_message.
>
> Signed-off-by: Frediano Ziglio
> ---
> server/main-channel-client.c | 3 ++
Acked-by: Christophe Fergeau
On Mon, Dec 11, 2017 at 10:28:08AM +, Frediano Ziglio wrote:
> This avoids to expose some detail about the channel.
> Like other APIs implement it move close to the part that handle
> it instead of have everything in reds.c.
>
> Signed-off-by: Frediano Ziglio
>
Acked-by: Christophe Fergeau
On Mon, Dec 11, 2017 at 10:28:04AM +, Frediano Ziglio wrote:
> There's no reason to copy mechname into mechlist to use mechlist
> instead of mechname.
>
> Signed-off-by: Frediano Ziglio
> ---
> server/red-stream.c | 7 ++-
> 1 file changed, 2 insertions(+),
Acked-by: Christophe Fergeau
On Mon, Dec 11, 2017 at 10:28:03AM +, Frediano Ziglio wrote:
> Signed-off-by: Frediano Ziglio
> ---
> server/red-stream.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/server/red-stream.c b/server/red-stream.c
> index 45e92a57..5ddf8c54 100644
> ---
Acked-by: Christophe Fergeau
On Mon, Dec 11, 2017 at 10:28:02AM +, Frediano Ziglio wrote:
> RedLinkInfo stores reds in it no need to pass every time.
>
> Signed-off-by: Frediano Ziglio
> ---
> server/reds.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --
>
> On Mon, Dec 11, 2017 at 10:28:07AM +, Frediano Ziglio wrote:
> > The list will persist will the SASL connection is not disposed
> > (or another sasl_listmech called).
>
> Where is this documented?
> "while the SASL connection.."
>
>
Yes, "will" typo.
Is documented in sasl.h:
* result
On Mon, Dec 11, 2017 at 10:28:07AM +, Frediano Ziglio wrote:
> The list will persist will the SASL connection is not disposed
> (or another sasl_listmech called).
Where is this documented?
"while the SASL connection.."
signature.asc
Description: PGP signature
___
Hi Frediano,
Note that there still is another call to red_stream_remove_watch,
(in reds_handle_ssl_accept), so consider changing the subject.
One comment below.
On 12/19/2017 03:38 PM, Frediano Ziglio wrote:
Signed-off-by: Frediano Ziglio
---
server/reds.c | 3 +--
1 file changed, 1 inser
On Mon, Dec 11, 2017 at 10:28:05AM +, Frediano Ziglio wrote:
> Avoid over complicated matching using quoting and a simple
> strstr operation.
I would explain the trick with sasl_mechlist prefix/suffix in the commit
log.
Looks good otherwise
>
> Signed-off-by: Frediano Ziglio
> ---
> serve
For the series,
Acked-by: Christophe Fergeau
On Wed, Dec 13, 2017 at 02:01:57PM +, Frediano Ziglio wrote:
> RedPipeItem does not contain a link anymore.
>
> Signed-off-by: Frediano Ziglio
> ---
> server/dcc.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/server
On Mon, Dec 11, 2017 at 10:27:58AM +, Frediano Ziglio wrote:
> Coverity complaint that this field should be protected by
> a mutex as other accesses are with the mutex locked.
> Use atomic operation. Not in an hot path in any case.
>
> Signed-off-by: Frediano Ziglio
> ---
> server/stat-file.
The .pdb files contain the debug information for the drivers. They
increase significantly the size of the installer, so it's better not to
ship them.
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index df8f7bc..841f01a 100644
--- a/Makefile
++
If these paths are unquoted, and the path contains spaces (C:\Program
Files (x86)\...), this could be exploited by putting a binary with a
crafted name (C:\Program.exe), leading to privilege escalation as this
is a service that is being started.
https://www.commonexploits.com/unquoted-service-path
On Sat, Dec 16, 2017 at 04:14:49AM -0500, Frediano Ziglio wrote:
> >
> > If these paths are unquoted, and the path contains spaces (C:\Program
> > Files (x86)\...), this could be exploited by putting a binary with a
> > crafted name (C:\Program.exe), leading to privilege escalation as this
> > is
Signed-off-by: Frediano Ziglio
---
server/reds.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index 9102c5122..66f24c72e 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -1791,7 +1791,6 @@ static void reds_handle_main_link(RedsState *reds,
On 12/11/2017 12:27 PM, Frediano Ziglio wrote:
Coverity complaint that this field should be protected by
a mutex as other accesses are with the mutex locked.
Use atomic operation. Not in an hot path in any case. >
Signed-off-by: Frediano Ziglio
Acked-by: Uri Lublin
---
server/stat-file.c
In case mcc->priv->initial_channels_list_sent is false we didn't
marshall any message so we should not call
red_channel_client_begin_send_message.
Signed-off-by: Frediano Ziglio
---
server/main-channel-client.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/server/main-cha
20 matches
Mail list logo
