james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tellier Benoit (JIRA)" <server-...@james.apache.org>
Subject [jira] [Updated] (JAMES-2278) IMAP QRESYNC (RFC-5162) is buggy
Date Thu, 04 Jan 2018 07:22:00 GMT

     [ https://issues.apache.org/jira/browse/JAMES-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Tellier Benoit updated JAMES-2278:
----------------------------------
    Description: 
As reported by lmilev on the gitter chat, passing known sequence sets to QRESYNC leads to
an error in the IMAP layer:


{code:java}
INFO | jvm 1 | 2018/01/03 12:25:15 | [imapserver-executor-17] ERROR org.apache.james.imap.processor.base.AbstractChainedProcessor
- Error while processing IMAP request
INFO | jvm 1 | 2018/01/03 12:25:15 | java.lang.IndexOutOfBoundsException: Index: 2, Size:
2
INFO | jvm 1 | 2018/01/03 12:25:15 | at java.util.ArrayList.rangeCheck(ArrayList.java:653)
INFO | jvm 1 | 2018/01/03 12:25:15 | at java.util.ArrayList.get(ArrayList.java:429)
INFO | jvm 1 | 2018/01/03 12:25:15 | at org.apache.james.imap.processor.AbstractSelectionProcessor.respond(AbstractSelectionProcessor.java:240)
INFO | jvm 1 | 2018/01/03 12:25:15 | at org.apache.james.imapserver.netty.ImapChannelUpstreamHandler.messageReceived(ImapChannelUpstreamHandler.java:194)
{code}

I tried to write a MPT test but it is not trivial as it depends on random values (UIDVALIDITY)
and non fixed values (MODSEQ). Moreover the code is messy, dirty and not explicit.

The incriminated lines seems to be:



{code:java}
if (knownUidsList.size() > index++) {
     int msnAsInt = msn.intValue();
     MessageUid knownUid = knownUidsList.get(index);
     // Complicated sequential stuff
}
{code}

As this little test shows it:

{code:java}
    @Test
    public void test() {
        int i = 0;
        System.out.println(i++);
        System.out.println(i++);
    }

// Will output
// 0
// 1
{code}

The index can clearly be out of range.

{code:java}
if (knownUidsList.size() > ++index) {
     int msnAsInt = msn.intValue();
     MessageUid knownUid = knownUidsList.get(index);
     // Complicated sequential stuff
}
{code}

Should fix the issue.

We should find a way to provide *at least* unit tests for that issue.

  was:
As reported by lmilev on the gitter chat, passing known sequence sets to QRESYNC leads to
an error in the IMAP layer:


{code:java}
INFO | jvm 1 | 2018/01/03 12:25:15 | [imapserver-executor-17] ERROR org.apache.james.imap.processor.base.AbstractChainedProcessor
- Error while processing IMAP request
INFO | jvm 1 | 2018/01/03 12:25:15 | java.lang.IndexOutOfBoundsException: Index: 2, Size:
2
INFO | jvm 1 | 2018/01/03 12:25:15 | at java.util.ArrayList.rangeCheck(ArrayList.java:653)
INFO | jvm 1 | 2018/01/03 12:25:15 | at java.util.ArrayList.get(ArrayList.java:429)
INFO | jvm 1 | 2018/01/03 12:25:15 | at org.apache.james.imap.processor.AbstractSelectionProcessor.respond(AbstractSelectionProcessor.java:240)
INFO | jvm 1 | 2018/01/03 12:25:15 | at org.apache.james.imapserver.netty.ImapChannelUpstreamHandler.messageReceived(ImapChannelUpstreamHandler.java:194)
{code}

I tried to write a MPT test but it is not trivial as it depends on random values (UIDVALIDITY)
and non fixed values (MODSEQ). Moreover the code is messy, dirty and not explicit.

The incriminated lines seems to be:

```
if (knownUidsList.size() > index++) {
     int msnAsInt = msn.intValue();
     MessageUid knownUid = knownUidsList.get(index);
     // Complicated sequential stuff
}
```

As this little test shows it:

```
    @Test
    public void test() {
        int i = 0;
        System.out.println(i++);
        System.out.println(i++);
    }

// Will output
// 0
// 1
```

The index can clearly be out of range.

```
if (knownUidsList.size() > ++index) {
     int msnAsInt = msn.intValue();
     MessageUid knownUid = knownUidsList.get(index);
     // Complicated sequential stuff
}
```

Should fix the issue.

We should find a way to provide *at least* unit tests for that issue.


> IMAP QRESYNC (RFC-5162) is buggy
> --------------------------------
>
>                 Key: JAMES-2278
>                 URL: https://issues.apache.org/jira/browse/JAMES-2278
>             Project: James Server
>          Issue Type: Bug
>            Reporter: Tellier Benoit
>
> As reported by lmilev on the gitter chat, passing known sequence sets to QRESYNC leads
to an error in the IMAP layer:
> {code:java}
> INFO | jvm 1 | 2018/01/03 12:25:15 | [imapserver-executor-17] ERROR org.apache.james.imap.processor.base.AbstractChainedProcessor
- Error while processing IMAP request
> INFO | jvm 1 | 2018/01/03 12:25:15 | java.lang.IndexOutOfBoundsException: Index: 2, Size:
2
> INFO | jvm 1 | 2018/01/03 12:25:15 | at java.util.ArrayList.rangeCheck(ArrayList.java:653)
> INFO | jvm 1 | 2018/01/03 12:25:15 | at java.util.ArrayList.get(ArrayList.java:429)
> INFO | jvm 1 | 2018/01/03 12:25:15 | at org.apache.james.imap.processor.AbstractSelectionProcessor.respond(AbstractSelectionProcessor.java:240)
> INFO | jvm 1 | 2018/01/03 12:25:15 | at org.apache.james.imapserver.netty.ImapChannelUpstreamHandler.messageReceived(ImapChannelUpstreamHandler.java:194)
> {code}
> I tried to write a MPT test but it is not trivial as it depends on random values (UIDVALIDITY)
and non fixed values (MODSEQ). Moreover the code is messy, dirty and not explicit.
> The incriminated lines seems to be:
> {code:java}
> if (knownUidsList.size() > index++) {
>      int msnAsInt = msn.intValue();
>      MessageUid knownUid = knownUidsList.get(index);
>      // Complicated sequential stuff
> }
> {code}
> As this little test shows it:
> {code:java}
>     @Test
>     public void test() {
>         int i = 0;
>         System.out.println(i++);
>         System.out.println(i++);
>     }
> // Will output
> // 0
> // 1
> {code}
> The index can clearly be out of range.
> {code:java}
> if (knownUidsList.size() > ++index) {
>      int msnAsInt = msn.intValue();
>      MessageUid knownUid = knownUidsList.get(index);
>      // Complicated sequential stuff
> }
> {code}
> Should fix the issue.
> We should find a way to provide *at least* unit tests for that issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message