similar to: Problem with CRAM and flac-1.1.2

On Tue, 2006-07-25 at 06:37 +0200, Josh Green wrote: > A user of CRAM (http://swami.sourceforge.net/cram.php) sent in a bug > report related to decoding of CRAM files. This issue occurs with > flac-1.1.2 but not previous versions (such as flac-1.1.1). Note that > the same file is used for this test (hopefully ruling out any issue with > the encoder). > > Details of the

sorry if I did not reply to this, answers below: --- Josh Green <josh@resonance.org> wrote: > On Tue, 2006-07-25 at 06:37 +0200, Josh Green wrote: > > A user of CRAM (http://swami.sourceforge.net/cram.php) sent in a > bug > > report related to decoding of CRAM files. This issue occurs with > > flac-1.1.2 but not previous versions (such as flac-1.1.1). Note >

Replying to myself once again, since I seem to have found the answer I was looking for. Sorry for the noise. It seems CRAM is indeed misusing FLAC, since stated in the Notes section of the FLAC format for the FRAME_HEADER is the fact that only block size values 0110 and 0111 can be used for variable block size data (i.e., the block size is specified as an 8 or 16 bit value at the end of the

On Thu, Dec 11, 2014 at 11:12:25AM +0100, Martijn van Beurden wrote: > Op 11-12-14 om 10:53 schreef Martijn van Beurden: > > Op 11-12-14 om 10:05 schreef Miroslav Lichvar: > >> but I'd rather see the real seeking bug fixed instead > > > > I think I might have a fix [...] So the problem is that FLAC__stream_decoder_process_single returns error before it finds a

Hi all, If I have code that does this: while (FLAC__stream_decoder_process_single (decoder)) /* Do something. */ ; I get an infinite loop. Shouldn't FLAC__stream_decoder_process_single return false if it gets to FLAC__STREAM_DECODER_END_OF_STREAM? If so, here's a patch. Cheers, Erik ------------------8<------------------8<------------------8<------------------

Op 11-12-14 om 10:05 schreef Miroslav Lichvar: > but I'd rather see the real seeking bug fixed instead I think I might have a fix, but it touches quite a bit of code, so it'll take some time. I think the problem is that because bogus headers might pop up in the stream of which the CRC checks out, the whole frame is decoded to validate that a frame is correct. The bogus header

sorry if I'm not reading this close enough, I'm ploughing through a bunch of emails here, but the source of this problem is what I consider a design defect in FLAC which uses frame numbers to save space, and confusing logic for determining whether the frame number or sample number is stored. if I had it to do again I would just have it store the sample number always. if you are going to

Federico Miyara wrote: ... > The file format allows some unused fields for future use, such as the > padding block. It could include a flag to indicate a change in the > format adding one more streaminfo byte which would allow up to 256 > channels (actually, 256 + 8), or it could trigger a new byte when 11111111. > > There is also an invalid block identifier (127) which could be

Erik de Castro Lopo wrote: > I think I have an alternative fix for the CVE which should not break > seeking. I'm working on getting an copy of the file with which to test. Patch applied and pushed. commit b4b2910bdca010808ccf2799f55562fa91f4347b Author: Erik de Castro Lopo <erikd at mega-nerd.com> Date: Wed Dec 10 18:54:16 2014 +1100

Howdy, I'm using dovecot and mysql users, and i'm creating the password with: ENCRYPT('some-passwd',CONCAT('$6$', SUBSTRING(SHA(RAND()), -16))) So far so good, everything's fine. Today saw that i didn't enabled CRAM-MD5, but if I do, and the (at least) IMAP client (roundcube/thunderbird/etc) issues CRAM-MD5 it doesn't authenticate. What am i doing wrong, or

Hi, after getting dovecot working with PostgreSQL and plaintext passwords I tried to use md5 encrypted passwords with mozilla. www.roughtrade.net/dovecot says that Mozilla only supports CRAM-MD5 and that CRAM-MD5 is included in HEAD. Now I have two questions: 1) Is the md5 hash stored in passdb with cram-md5 the same as in digest-md5? 2) Is a new dovecot stable build planned within the next two

/etc/dovecot.conf: auth default { mechanisms=plain login cram-md5 passdb { #.............. Windows Live Mail: CRAM-MD5 authentication failed. This could be due to a lack of memory on your system. Your IMAP command could not be sent to the server, due to non-network errors. This could, for example, indicate a lack of memory on your system. Configuration: Account: Sheltoncomputers

I don't desagree with your vision, but if the use of CRAM-XXXX has to use plaint text password's on the server there's a dark side, or there's a CRAM-XXX that can use encrypted on server side? There's always the thing that can clients don't support it. I think i'm not wrong with what i said, On 20 Jun 2019, at 02:53, FUSTE Emmanuel via dovecot <dovecot at

On 19.6.2019 7.48, Alexander Dalloz via dovecot wrote: > Am 19.06.2019 um 00:04 schrieb Jorge Bastos via dovecot: >> Howdy, >> >> I'm using dovecot and mysql users, and i'm creating the password with: >> >> ENCRYPT('some-passwd',CONCAT('$6$', SUBSTRING(SHA(RAND()), -16))) >> >> So far so good, everything's fine. >>

hello dovecot community, question; if my user database and dovecot installation is currently setup to use plain login passwords, and i want to convert to cram-md5, after i configure dovecot accordingly and reset passwords into cram-md5, if anyone uses plain login method again in the future, will it still work? or must they always from this point on use encrypted passwords? Thanks. -- Thanks,

Hello. dovecot 2.2.26.0 When testing nopassword extra field (http://wiki2.dovecot.org/PasswordDatabase/ExtraFields) with CRAM-MD5 dovecot doesn't allow any password (while it should) and returns " Authentication failed" while in logs: Nov 17 08:22:34 auth-worker(1551): Info: sql(pepe,127.0.0.1,<Y8amDXpBptV/AAAB>): Requested CRAM-MD5 scheme, but we have a NULL password

Le 20/06/2019 ? 12:25, @lbutlr via dovecot a ?crit?: > On 20 Jun 2019, at 04:14, Jorge Bastos via dovecot <dovecot at dovecot.org> wrote: >> I don't desagree with your vision, but if the use of CRAM-XXXX has to use >> plaint text password's on the server there's a dark side, or there's a >> CRAM-XXX that can use encrypted on server side? There's

When using proxy_maybe CRAM-MD5 authentication fails when the connection is proxied. Is this expected behavior? Is proxy_maybe too simplified for this case? We're using SQL so I could rewrite the query with IFs to fake proxy_maybe and return the password as NULL and nologin as Y, but if it works that way couldn't it work with proxy_maybe? This works: password_query = \ SELECT NULL AS

Hi Timo, Mozilla 1.5 doesn't understand DIGEST-MD5; it only speaks CRAM-MD5 or PLAIN. Maybe other clients have the same problem. My users like Mozilla, so I wrote new code for Dovecot to speak CRAM-MD5, using your mech-digest-md5.c as a reference. Attached diff in two formats i) for current CVS ii) against last release both tested and working with Mozilla and KMail's CRAM-MD5. I

Hello, I have a program that is given a random file and needs to determine whether it is Vorbis or FLAC. For Vorbis, there are various places where I can infer that I have a bad stream. But for FLAC, when I call either FLAC__stream_decoder_process_until_end_of_metadata or FLAC__stream_decoder_process_single, it searches the entire file before giving up. I'd like it to stop searching as soon