Discussion:
Bug#854804: saned: SANE_NET_CONTROL_OPTION response packet may contain memory contents of the server
Add Reply
Jörg Frings-Fürst
2017-02-11 04:54:37 UTC
Reply
Permalink
Raw Message
tags 854804 + moreinfo
thanks

Hello Kritphong,

thank you for spending your time helping to make Debian better with
this bug report.

I have add the sane-devel ML as cc.


Am Freitag, den 10.02.2017, 10:33 -0500 schrieb Kritphong
Package: sane-utils
Version: 1.0.25-3
Severity: grave
Tags: security upstream
Justification: user security hole
Dear Maintainer,
When saned received a SANE_NET_CONTROL_OPTION packet with value_type ==
SANE_TYPE_STRING and value_size larger than the actual length of the
requested string, the response packet from the server contains a string
object as long as value_size in the request. The bytes following the
actual string appears to contain memory contents from the server.
Please let me explain:

You have found one or more parts in the code where a string with an
incorrect value_size is transferred? Then please tell us where.

Or is there an other problem?

Please give us more infos and remove the tag moreinfo with your answer.
It may be possible to trigger this bug with other packet types, but I
have not verified this.
I have previously filed a bug in the SANE bug tracker on Alioth
(#315576), but I received no response.
Debian Release: 9.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.8.0-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
ii adduser 3.115
ii debconf [debconf-2.0] 1.5.60
ii init-system-helpers 1.47
ii libavahi-client3 0.6.32-2
ii libavahi-common3 0.6.32-2
ii libc6 2.24-9
ii libieee1284-3 0.2.11-13
ii libjpeg62-turbo 1:1.5.1-2
ii libpng16-16 1.6.28-1
ii libsane 1.0.25-3
ii libsystemd0 232-6
ii libusb-1.0-0 2:1.0.21-1
ii lsb-base 9.20161125
ii update-inetd 4.44
sane-utils recommends no packages.
ii avahi-daemon 0.6.32-2
pn unpaper <none>
-- debconf information excluded
CU
Jörg
--
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key        : 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-FÌrst
D-54470 Lieser

Threema: SYR8SJXB

IRC: j_f-***@freenode.net
     j_f-***@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.
Kritphong Mongkhonvanit
2017-02-11 17:16:04 UTC
Reply
Permalink
Raw Message
tags 854804 - moreinfo
thanks

On Sat, Feb 11, 2017 at 11:54 AM, Jörg Frings-FÌrst
Post by Jörg Frings-Fürst
tags 854804 + moreinfo
thanks
Hello Kritphong,
thank you for spending your time helping to make Debian better with
this bug report.
I have add the sane-devel ML as cc.
Am Freitag, den 10.02.2017, 10:33 -0500 schrieb Kritphong
Package: sane-utils
Version: 1.0.25-3
Severity: grave
Tags: security upstream
Justification: user security hole
Dear Maintainer,
When saned received a SANE_NET_CONTROL_OPTION packet with
value_type ==
SANE_TYPE_STRING and value_size larger than the actual length of the
requested string, the response packet from the server contains a string
object as long as value_size in the request. The bytes following the
actual string appears to contain memory contents from the server.
You have found one or more parts in the code where a string with an
incorrect value_size is transferred? Then please tell us where.
I found that the transferred string in the value field of
SANE_NET_CONTROL_OPTION response packet is always the same size as the
one requested, even if the actual string is shorter. I assume that this
is intentional since the string is NULL-terminated. However, the part
beyond the NULL-terminator appears to be uninitialized memory from the
server, which can potentially contain sensitive information. I have yet
to locate where in SANE's source code this is happening, but I am able
to see the uninitialized memory in Wireshark, which suggests that it
actually comes from the server rather than from my machine.

I also have a proof-of-concept that demonstrates this if you'd like to
take a look at it.
Post by Jörg Frings-Fürst
Or is there an other problem?
Please give us more infos and remove the tag moreinfo with your answer.
It may be possible to trigger this bug with other packet types, but I
have not verified this.
I have previously filed a bug in the SANE bug tracker on Alioth
(#315576), but I received no response.
Debian Release: 9.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.8.0-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
ii adduser 3.115
ii debconf [debconf-2.0] 1.5.60
ii init-system-helpers 1.47
ii libavahi-client3 0.6.32-2
ii libavahi-common3 0.6.32-2
ii libc6 2.24-9
ii libieee1284-3 0.2.11-13
ii libjpeg62-turbo 1:1.5.1-2
ii libpng16-16 1.6.28-1
ii libsane 1.0.25-3
ii libsystemd0 232-6
ii libusb-1.0-0 2:1.0.21-1
ii lsb-base 9.20161125
ii update-inetd 4.44
sane-utils recommends no packages.
ii avahi-daemon 0.6.32-2
pn unpaper <none>
-- debconf information excluded
CU
Jörg
--
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key : 8CA1D25D
CAcert Key S/N : 0E:D4:56
Old pgp Key: BE581B6E (revoked since 2014-12-31).
Jörg Frings-FÌrst
D-54470 Lieser
Threema: SYR8SJXB
- Please send me a picture from the nature at your home.
Jörg Frings-Fürst
2017-02-12 07:43:23 UTC
Reply
Permalink
Raw Message
severity 854804 important
tags 854804 + moreinfo - security
thanks


Hello Kritphong,


Am Sonntag, den 12.02.2017, 00:16 +0700 schrieb Kritphong
Post by Kritphong Mongkhonvanit
tags 854804 - moreinfo
thanks
[...]
Post by Kritphong Mongkhonvanit
Post by Jörg Frings-Fürst
Am Freitag, den 10.02.2017, 10:33 -0500 schrieb Kritphong
[...]
Post by Kritphong Mongkhonvanit
Post by Jörg Frings-Fürst
Dear Maintainer,
When saned received a SANE_NET_CONTROL_OPTION packet with value_type ==
SANE_TYPE_STRING and value_size larger than the actual length of the
requested string, the response packet from the server contains a string
object as long as value_size in the request. The bytes following the
actual string appears to contain memory contents from the server.
You have found one or more parts in the code where a string with an
incorrect value_size is transferred? Then please tell us where.
I found that the transferred string in the value field of SANE_NET_CONTROL_OPTION response packet  is always the same size as the one requested, even if the actual string is shorter. I assume that this is intentional since the string is NULL-terminated. However, the part beyond the NULL-terminator appears to be uninitialized memory from the server, which can potentially contain sensitive information. I have yet to locate where in SANE's source code this is happening, but I am able to see the uninitialized memory in Wireshark, which suggests that it actually comes from the server rather than from my machine.
[...]

At a short code search I have found a point of use in net.c.

The authors are aware that the strings can be shorter than the
transferred size. You have written the appropriate code that ensures
that the strings only use the part until the final NULL.

Furthermore, before using the structure, it is overwritten with NULL.

At this point I don't see any security hole. So I set the severity to
important. In the future, I will close the bug, unless you create new
threats.



CU 
Jörg
--
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key        : 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-FÌrst
D-54470 Lieser

Threema: SYR8SJXB

IRC: j_f-***@freenode.net
     j_f-***@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.
Kritphong Mongkhonvanit
2017-02-12 09:54:51 UTC
Reply
Permalink
Raw Message
Hello Jörg,
Post by Jörg Frings-Fürst
severity 854804 important
tags 854804 + moreinfo - security
thanks
Hello Kritphong,
Am Sonntag, den 12.02.2017, 00:16 +0700 schrieb Kritphong
Post by Kritphong Mongkhonvanit
tags 854804 - moreinfo
thanks
[...]
Post by Kritphong Mongkhonvanit
Post by Jörg Frings-Fürst
Am Freitag, den 10.02.2017, 10:33 -0500 schrieb Kritphong
[...]
Post by Kritphong Mongkhonvanit
Post by Jörg Frings-Fürst
Dear Maintainer,
When saned received a SANE_NET_CONTROL_OPTION packet with value_type ==
SANE_TYPE_STRING and value_size larger than the actual length of the
requested string, the response packet from the server contains a string
object as long as value_size in the request. The bytes following the
actual string appears to contain memory contents from the server.
You have found one or more parts in the code where a string with an
incorrect value_size is transferred? Then please tell us where.
I found that the transferred string in the value field of SANE_NET_CONTROL_OPTION response packet is always the same size as the one requested, even if the actual string is shorter. I assume that this is intentional since the string is NULL-terminated. However, the part beyond the NULL-terminator appears to be uninitialized memory from the server, which can potentially contain sensitive information. I have yet to locate where in SANE's source code this is happening, but I am able to see the uninitialized memory in Wireshark, which suggests that it actually comes from the server rather than from my machine.
[...]
At a short code search I have found a point of use in net.c.
The authors are aware that the strings can be shorter than the
transferred size. You have written the appropriate code that ensures
that the strings only use the part until the final NULL.
Furthermore, before using the structure, it is overwritten with NULL.
At this point I don't see any security hole. So I set the severity to
important. In the future, I will close the bug, unless you create new
threats.
I do realize that there is a part where the memory was zeroed in net.c.
However, there must be somewhere else where uninitialized memory was
copied and sent since the bytes following the string are not exclusively
zeros.

Please take a look at the decoded SANE_NET_CONTROL_OPTION response
packet I captured in Wireshark below.

....................JPEG............SignerIdentifier........digestAlgori
thm......................................................l.=...@@.......
....X...........................................8...........AlgorithmIde
ntifier.....signedAttrs.................................................
.............`......................................................x...
`...........SignedAttributes............................................
........................................`...............X...0...........
....................................signatureAlgorithm..................
***@...........8...X................
....................g.............AlgorithmIdentifier.....signature.....
.........................................................;***@..........
..........................................................unsignedAttrs.
....................................................../#...`..X.......p.
......8...................................h...............SignedAttribut
es....................................

Here's an excerpt of the corresponding hex stream. I omitted the part
after the string since it looks like it may contain sensitive
information.

00000000 00000000 00000003 00000400 00000400 4a504547 00 (omitted)

As you can see, the string "JPEG" is NULL-terminated at byte 25, and the
bytes after that are clearly not all zeroes. Both value_size (the 4th
word) and the length of the string object (the 5th word) are set to
0x400, so they must have been sent by saned as a part of the string
object.
Post by Jörg Frings-Fürst
CU
Jörg
Olaf Meeuwissen
2017-02-14 14:04:00 UTC
Reply
Permalink
Raw Message
Hi Kritphong, Jörg,
Hello Jörg,
[snip BTS control commands]
Hello Kritphong,
Am Sonntag, den 12.02.2017, 00:16 +0700 schrieb Kritphong
[snip BTS control commands]
[...]
Post by Jörg Frings-Fürst
Am Freitag, den 10.02.2017, 10:33 -0500 schrieb Kritphong
[...]
Post by Jörg Frings-Fürst
Dear Maintainer,
When saned received a SANE_NET_CONTROL_OPTION packet with value_type ==
SANE_TYPE_STRING and value_size larger than the actual length of the
requested string, the response packet from the server contains a string
object as long as value_size in the request. The bytes following the
actual string appears to contain memory contents from the server.
You have found one or more parts in the code where a string with an
incorrect value_size is transferred? Then please tell us where.
I found that the transferred string in the value field of
SANE_NET_CONTROL_OPTION response packet is always the same size as
the one requested, even if the actual string is shorter. I assume
that this is intentional since the string is
NULL-terminated. However, the part beyond the NULL-terminator
appears to be uninitialized memory from the server, which can
potentially contain sensitive information. I have yet to locate
where in SANE's source code this is happening, but I am able to see
the uninitialized memory in Wireshark, which suggests that it
actually comes from the server rather than from my machine.
[...]
At a short code search I have found a point of use in net.c.
The authors are aware that the strings can be shorter than the
transferred size. You have written the appropriate code that ensures
that the strings only use the part until the final NULL.
That's the `case SANE_TYPE_STRING` in backend/net.c#1753.
Furthermore, before using the structure, it is overwritten with NULL.
That's the `memset` in backend/net.c#1767, right? Or are you referring
to frontend/saned.c#1997?
At this point I don't see any security hole. So I set the severity to
important. In the future, I will close the bug, unless you create new
threats.
I do realize that there is a part where the memory was zeroed in net.c.
However, there must be somewhere else where uninitialized memory was
copied and sent since the bytes following the string are not exclusively
zeros.
Please take a look at the decoded SANE_NET_CONTROL_OPTION response
If it's in the *response*, then it comes from frontend/saned.c, not the
backend/net.c code. I've been chasing the code up and down and am by
now fairly sure it is caused somewhere in the sanei/sanei_wire.c code.
I just don't see where.

Could you run

SANE_DEBUG_SANEI_WIRE=128 saned -d128 2> saned.log

reproduce and provide the saned.log (compressed if big)?
# Running saned through valgrind may also turn up hints, BTW.
packet I captured in Wireshark below.
....................JPEG............SignerIdentifier........digestAlgori
....X...........................................8...........AlgorithmIde
ntifier.....signedAttrs.................................................
.............`......................................................x...
`...........SignedAttributes............................................
........................................`...............X...0...........
....................................signatureAlgorithm..................
....................g.............AlgorithmIdentifier.....signature.....
..........................................................unsignedAttrs.
....................................................../#...`..X.......p.
......8...................................h...............SignedAttribut
es....................................
Here's an excerpt of the corresponding hex stream. I omitted the part
after the string since it looks like it may contain sensitive
information.
00000000 00000000 00000003 00000400 00000400 4a504547 00 (omitted)
As you can see, the string "JPEG" is NULL-terminated at byte 25, and the
bytes after that are clearly not all zeroes. Both value_size (the 4th
word) and the length of the string object (the 5th word) are set to
0x400, so they must have been sent by saned as a part of the string
object.
Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
--
sane-devel mailing list: sane-***@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-***@lists.alioth.debian.org
Olaf Meeuwissen
2017-02-19 07:53:28 UTC
Reply
Permalink
Raw Message
Hi Kritphong,
Post by Olaf Meeuwissen
Could you run
SANE_DEBUG_SANEI_WIRE=128 saned -d128 2> saned.log
reproduce and provide the saned.log (compressed if big)?
The requested log is attached.
Thanks!!

I didn't write the code but, if my analysis is correct, it is actually
worse than sending server memory content over the wire. It looks like
saned is clobbering memory, i.e. it's writing past the end of allocated
memory, as well.

According to your log (at line 4007), the saned process gets its first
SANE_NET_CONTROL_OPTION request. That request tries to fetch the value
of the 8th option (compression) which is a string value that can be up
to 1024 (0x400) bytes long. The request also sends a value with this
request, a NUL-terminated 1-byte long empty string.

# Code line references against f450049b.

At this point we are around line 4045 of the log. Now let's switch to
the code. The incoming request is handled in the case statement on line
1979 of frontend/saned.c. The sanei_w_control_option_req() call has
taken care of the incoming request and the req structure now contains

req.handle = 0;
req.option = 8; // 'compression'
req.action = 0; // SANE_ACTION_GET_VALUE
req.value_type = 3; // SANE_TYPE_STRING
req.value_size = 1024;
req.value = "\0";

Most importantly, req.value was allocated as a *1*-byte buffer. This
happens in the if-block starting at line 204 in sanei/sanei_wire.c.
Note that the `len` is passed back up via `len_ptr` but that that value
does *not* make it back to req.value_size because the w_option_value()
call in sanei_w_control_option_req() passes by value, not by reference.

This means that sane_control_option() on line 1999 in frontend/saned.c
happily passes a 1-byte buffer to the backend. The backend assumes that
it can store up to 1024 bytes in that buffer and writes a NUL-terminated
five byte "JPEG" string into the 1-byte buffer. Oops!

On line 2003 of frontend/saned.c the reply.value_size is set to the
value fo req.value_size (still 1024) and sanei_w_reply gets a reply
struct that:

- has a pointer to a 1-byte block of memory
- which holds a five byte string value
- that is sent back as a 1024 buffer

Ouch!

This code has been around since the summer of 1999. Seeing that we have
not had anyone complain about this before, please check my analysis with
care. I have only "eyeballed" the code. I have not tried to reproduce
or run things in a debugger or anything.

Attached is a minimal hack/patch that *tries* to fix it. I have only
checked that it compiles. Could you take a look at whether it fixes
the issue and does not break saned?

Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
Olaf Meeuwissen
2017-02-20 12:13:12 UTC
Reply
Permalink
Raw Message
Hi Kritphong,
Hi Olaf,
Post by Olaf Meeuwissen
Attached is a minimal hack/patch that *tries* to fix it. I have only
checked that it compiles. Could you take a look at whether it fixes
the issue and does not break saned?
Thank you for your patch. I performed some basic tests and it seems to
fix the issue for me. It doesn't break saned as far as I can tell.
That's good news.

@sane-devel> If some of you could review the patch[0] and do some
testing that would be appreciated.

[0] http://lists.alioth.debian.org/pipermail/sane-devel/2017-February/035054.html

If someone is willing to pull saned through valgrind and post the
results to the mailing list (don't spam the Debian BTS with this,
please), that'd be appreciated as well.
# I'm a just a wee bit worried there is more amiss with saned.

Alternatively, open a tracker issue[1] and assign it to me.

[1] https://alioth.debian.org/tracker/?func=add&group_id=30186&atid=410366

Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
--
sane-devel mailing list: sane-***@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-***@lists.alioth.debian.org
Jörg Frings-Fürst
2017-02-25 20:20:42 UTC
Reply
Permalink
Raw Message
Hi,

the bug[1] is now an security issue[2] and has a CVE-Number[3].

I need your comment about the patch.


CU
Jörg


[1]https://alioth.debian.org/tracker/index.php?func=detail&aid=315576&group_id=30186&atid=410366
[2]https://security-tracker.debian.org/tracker/CVE-2017-6318
[3]https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-6318
--
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key        : 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-FÌrst
D-54470 Lieser

Threema: SYR8SJXB

IRC: j_f-***@freenode.net
     j_f-***@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.
Olaf Meeuwissen
2017-03-05 10:02:14 UTC
Reply
Permalink
Raw Message
Hi Jörg,

Sorry for the belated follow-up.
Post by Jörg Frings-Fürst
Hi,
the bug[1] is now an security issue[2] and has a CVE-Number[3].
I need your comment about the patch.
I wrote the patch so I am not sure how qualified I am commenting on it
(and I have no idea what kind of comments you're after) but here goes
anyway.

Kritphong has reported[4] that the patch makes the problem he reported
go away and does not obviously break saned.

I wrote the patch to take care only of the issue reported in the least
intrusive way. Unfortunately, that also means the patch cannot really
address the issue where it originates. It merely tries to repair the
broken logic in sanei/sanei_wire.c under very specific conditions (as
you can see from the initial condition in the patch.

I've commented a bit more on the patch in [5].

The FIXME in the patch, as also explained in [5], is to remind folks of
the fact that backends may send strings in buffers that are larger than
the length of the string. In that case, w->allocated_memory would end
up being larger than the amount that is actually still allocated. This
may, over time, lead to unwarranted SANE_STATUS_NO_MEM return values,
i.e. resource starvation, which may be a security issue in and of itself
as it would provide a way to trigger a DOS for saned.
Post by Jörg Frings-Fürst
[1]https://alioth.debian.org/tracker/index.php?func=detail&aid=315576&group_id=30186&atid=410366
[2]https://security-tracker.debian.org/tracker/CVE-2017-6318
[3]https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-6318
[4]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854804#59
[5]https://lists.alioth.debian.org/pipermail/sane-devel/2017-March/035066.html

Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
--
sane-devel mailing list: sane-***@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-***@lists.alioth.debian.org
Jörg Frings-Fürst
2017-04-17 19:57:03 UTC
Reply
Permalink
Raw Message
Hi,

Debian is about to be released. Sane-backends do not have to contain
any serious errors.

I need your evaluation of the patch.


Many thanks

CU
Jörg
Post by Jörg Frings-Fürst
Hi,
the bug[1] is now an security issue[2] and has a CVE-Number[3].
I need your comment about the patch.
CU
Jörg
[1]https://alioth.debian.org/tracker/index.php?func=detail&aid=315576&group_id=30186&atid=410366
[2]https://security-tracker.debian.org/tracker/CVE-2017-6318
[3]https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-6318
--
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key        : 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-FÌrst
D-54470 Lieser

Threema: SYR8SJXB
Wire: @joergfringsfuerst

IRC: j_f-***@freenode.net
     j_f-***@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.
Olaf Meeuwissen
2017-04-18 12:33:29 UTC
Reply
Permalink
Raw Message
Hi Jörg,
Post by Jörg Frings-Fürst
Hi,
Debian is about to be released. Sane-backends do not have to contain
any serious errors.
I need your evaluation of the patch.
I sent my evaluation[1] last month. Didn't you get it? Is anything
wrong with the evaluation? If so, please elaborate.

[1] https://lists.alioth.debian.org/pipermail/sane-devel/2017-March/035067.html

Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
--
sane-devel mailing list: sane-***@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-***@lists.alioth.debian.org
Loading...